Particularly on Android, when a WebXR Session starts, it renders across
the full screen. This can cause the Renderer process to be viewed as
unimportant and it can then get backgrounded. However, the Renderer
process is exactly what is responsible for providing the content that
is now being rendered. This plumbs a new boolean through so that the
presence of a WebXR session can elevate the importance of the renderer
process similar to how a media stream does.
Fixed: 378956985
Change-Id: Iafcc031a9e562d80170d78596db6cdd3c049faa8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6271450
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Piotr Bialecki <bialpio@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1422782}
Move the InternalWebUIConfig class to content/public/browser so that
it can be leveraged by content/ WebUIs. The WebxrInternals UI is
migrated to use the config in this CL as a demonstration, since its
OWNERS said the UI could be placed behind an internal debugging UIs
pref in a recent Chromium WebUI survey.
The implementation of InternalWebUIConfig relies on some chrome-
specific logic, notably prefs and the InternalDebugPagesDisabled
WebUI page interstitial. Based on advice from content/ OWNERS,
move this logic out of InternalWebUIConfig and add an API to the
ContentBrowserClient for overriding internal WebUIs with a default
implementation that is a no-op/never overrides. Implement this
API from ChromeContentBrowserClient using the logic that was
previously in InternalWebUIConfig.
Also migrating the InternalWebUIConfig unit test by splitting it
into a new unit test for the content portion of the class in
content/browser/webui and an additional unit test for
ChromeContentBrowserClient that tests the Chrome-specific logic
(i.e. respecting the pref and feature flag).
Bug: 379889249
Change-Id: I2d0b3df8997b7d5b4a717b4dc08e5156b40e46cc
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6096297
Reviewed-by: Demetrios Papadopoulos <dpapad@chromium.org>
Reviewed-by: Robert Ogden <robertogden@chromium.org>
Code-Coverage: findit-for-me@appspot.gserviceaccount.com <findit-for-me@appspot.gserviceaccount.com>
Commit-Queue: Rebekah Potter <rbpotter@chromium.org>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1398292}
NOTREACHED() and NOTREACHED_IN_MIGRATION() are both CHECK-fatal now.
The former is [[noreturn]] so this CL also performs dead-code removal
after the NOTREACHED().
This CL does not attempt to do additional rewrites of any surrounding
code, like:
if (!foo) {
NOTREACHED();
}
to CHECK(foo);
Those transforms take a non-trivial amount of time (and there are
thousands of instances). Cleanup can be left as an exercise for the
reader.
This does clean up kCrashOnDanglingBrowserContext as both paths of the
kill switch are currently fatal. This has been rolled out for a long
time.
Bug: 40580068, 40062641
Change-Id: Ib88e710d003e2e48df3fc502ca54d2341d157a0e
Cq-Include-Trybots: luci.chromium.try:linux-dcheck-off-rel
Low-Coverage-Reason: OTHER Should-be-unreachable code
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5974816
Reviewed-by: Łukasz Anforowicz <lukasza@chromium.org>
Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Auto-Submit: Peter Boström <pbos@chromium.org>
Reviewed-by: Sam McNally <sammc@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1376522}
This removes the additional delay that was added on Windows before
requesting additional permissions as https://crrev.com/c/5878696 fixed
the underlying issue. This is only a partial revert as the refactoring
into `DoRequestPermissions` is cleaner than what previously existed, and
allows an easier path forward if we need to add this back again.
Bug: 364669911
Change-Id: Ifdc776864a2ce65571be3baeb24b7d89bb7bad54
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5906046
Commit-Queue: Brandon Jones <bajones@chromium.org>
Reviewed-by: Brandon Jones <bajones@chromium.org>
Auto-Submit: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1363807}
The 'webgpu' feature enables the session to use WebGPU layers and
prevents the use of WebGL layers. It also changes the projection
matrix calculations to match WebGPU's clip space.
Worth noting that actually attempting to create a layer with this feature right now will result in the session being rejected since the backends don't indicate that it's supported. This is just an incremental step towards the feature support.
Bug: 359418629
Change-Id: If22e6c8a6b9c6d03b935601e13d9a2972099c86e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5868084
Reviewed-by: Mustafa Emre Acer <meacer@chromium.org>
Commit-Queue: Brandon Jones <bajones@chromium.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1361344}
On Windows, when prompting for a new permission as the result of a
previous permission request resolving there appears to be a race where
the actual permission bubble/chip's deleted notification comes through
on the same thread *after* the permission code thinks it has been
deleted. This event seems to almost always come after the creation of
the permission chip for the new permission, which causes the permissions
code to assume that the window deletion that just came through was for
the new bubble that was just created, and thus deletes the window and
blocks the newly requested permission.
In order to work around this, this change adds a delay before the new
permission is requested, which will allow the window dismissed event to
be processed. This is not ideal, but will temporarily resolve the issue
while a more thorough fix is pursued.
Bug: 364669911
Change-Id: I157676c4fced4fc3732764f2363471a6069bad03
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5842508
Reviewed-by: Piotr Bialecki <bialpio@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1354140}
If the object requesting a permission attempts to request a new
permission in it's result callback, then the PermissionRequestManager
may decide to preempt the previous permission request with the new
permission. However, this callback is called via an iterator on the
`requests_` object and preempting a callback clears this `requests_`
object leading to an invalid iterator and thus a crash.
As a previous workaround it had seemed like sites could post a task
to handle the new permission request; however, it seems that there may
often be a race where the new permission is requested, but the bubble
is scheduled for destruction. This causes the bubble to get destroyed
and for the new/secondary permission to be rejected.
WebXR encounters this because we need to first request the overall
permission to enter an XR session, and then if that is granted, we
want to prompt for any permissions that may be required for features
that were requested to be enabled on the session. However, if the
initial session level permission is rejected, we don't want to prompt
for permissions on any of the features.
This change removes the `PostTask` logic from WebXR that was causing
permissions to be autorejected and adds further logic to
PermissionRequestManager to prevent a request from being preempted if
it is in the final stages of being resolved (e.g. a decision was already
made).
Fixed: 357776212
Change-Id: I54c78ceec7daecba530b397f7bbb74492e57858f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5825068
Reviewed-by: Andy Paicu <andypaicu@chromium.org>
Auto-Submit: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1350249}
Triggers the prompt for the Hand Tracking permission when needed and
adds an entry to PageInfo on both Desktop and Android to allow testing
this feature.
Low-Coverage-Reason: HARD_TO_TEST New cases to uncovered switch
statements. Infeasible to add new coverage.
Bug: 359418633
Change-Id: Ic93ae81427829dc71a59b82c78924a55d6b9f55e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5785803
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Brandon Jones <bajones@chromium.org>
Reviewed-by: Christian Dullweber <dullweber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1345603}
WebXr triggers additional permissions requests for features only if the
general permission for the session was granted. This is done to ensure
that the user only sees the prompts for additional features (which may
be optional) if they agree to the overall immersive experience.
When requesting a permission, the permissions infrastructure determines
if the new permission should "preempt" the current permission request.
In some cases for WebXr, this "feature" level permission is chosen
to preempt the overall permission. This causes some re-entrant behavior,
as the list of permissions currently being iterated over to resolve the
user's response is cleared in preparation for requesting the new
permission. When flow returns to finish the user's response to the first
permission, the iterator being used by the loop is now invalid, and
errors occur.
While this likely should be fixed within the permissions code, WebXr is
one of the few places that has such a complex flow as to later prompt
for additional features ourselves in this decision callback. This change
thus patches the WebXr code until a decision about a proper and more
thorough fix can be decided upon within permissions code, in order to
unblock ongoing work for features that require a new permission.
Bug: 357776212
Change-Id: I785613eeba3d6f08feb9111a748f469e1cb74068
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5785799
Reviewed-by: Brandon Jones <bajones@chromium.org>
Commit-Queue: Brandon Jones <bajones@chromium.org>
Auto-Submit: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1341173}
Accessing an invalid iterator can sometimes be a security
issue and these checks are cheap, so upgrade to CHECKs.
Added checks are NotFatalUntil::M130.
`base/not_fatal_until.h` is added using tools/add_header.py,
this may result in some main-file (foo.h for foo.cc) headers
being re-sorted to be first as part `git cl format` of this CL.
For this CL instances were located with a weggli query:
```
weggli --verbose=1 --cpp \
'DCHECK($var != _.end());' \
-p 'DCHECK(_.end() != $var);' \
-p 'DCHECK_NE($var, _.end());' \
-p 'DCHECK_NE(_.end(), $var);'
```
which should avoid any potentially expensive calculations
of the thing to be matched against .end().
This CL was uploaded by git cl split.
R=alexmos@chromium.org, boliu@chromium.org, fabiansommer@chromium.org, mmenke@chromium.org, peter@chromium.org
Bug: 351745839
Change-Id: Icfe179b0d14dd9af5cfde3a51497c1b88964d7c0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5689315
Reviewed-by: Peter Beverloo <peter@chromium.org>
Commit-Queue: Alex Gough <ajgo@chromium.org>
Reviewed-by: Bo Liu <boliu@chromium.org>
Reviewed-by: Fabian Sommer <fabiansommer@chromium.org>
Reviewed-by: mmenke <mmenke@chromium.org>
Auto-Submit: Alex Gough <ajgo@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1326308}
Suppress unsafe buffer usage on a file-by-file basis. Out of
approximately 5850 .cc and .h files only roughly 160 files fail
compilation with the unsafe buffers warning.
Suppress only, by inserting boilerplate into affected files. Do not
re-write any code to work around the issues. Properly fixing each file
will be done in follow-up CLs.
//content/ is not removed from unsafe_bufers_paths.txt file and will be
also done as a follow-up, so it makes potential reverts simpler.
Bug: 342213636
Change-Id: I4a936e63dea95a78951f7bfae6d5487708ae3c0b
AX-Relnotes: n/a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5608913
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Owners-Override: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Nasko Oskov <nasko@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1312393}
This was generated by replacing " NOTREACHED()" with
" NOTREACHED_IN_MIGRATION()" and running git cl format.
This prepares for making NOTREACHED() [[noreturn]] alongside
NotReachedIsFatal migration of existing inventory.
Bug: 40580068
Change-Id: I3b48b89911ac5e9ffcb211622992f917f8f9e8d9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5539619
Auto-Submit: Peter Boström <pbos@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
Owners-Override: Lei Zhang <thestig@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: Peter Boström <pbos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1301096}
The canonical bug format is TODO(crbug.com/<id>). TODOs of the
following forms will all be migrated to the new format:
- TODO(crbug.com/<old id>)
- TODO(https://crbug.com/<old id>)
- TODO(crbug/<old id>)
- TODO(crbug/monorail/<old id>)
- TODO(<old id>)
- TODO(issues.chromium.org/<old id>)
- TODO(https://issues.chromium.org/<old id>)
- TODO(https://issues.chromium.org/u/1/issues/<old id>)
- TODO(bugs.chromium.org/<old id>)
Bug id mapping is sourced from go/chrome-on-buganizer-prod-issues.
See go/crbug-todo-migration for details.
#crbug-todo-migration
Bug: b/321899722
Change-Id: Ibc66b8c440e4bcdef414e77fef4d9874d2ea9951
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5493800
Auto-Submit: Alison Gale <agale@chromium.org>
Commit-Queue: Alison Gale <agale@chromium.org>
Reviewed-by: Peter Boström <pbos@chromium.org>
Owners-Override: Alison Gale <agale@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1293330}
The canonical bug format is TODO(crbug.com/<id>). TODOs of the
following forms will all be migrated to the new format:
- TODO(crbug.com/<old id>)
- TODO(https://crbug.com/<old id>)
- TODO(crbug/<old id>)
- TODO(crbug/monorail/<old id>)
- TODO(<old id>)
- TODO(issues.chromium.org/<old id>)
- TODO(https://issues.chromium.org/<old id>)
- TODO(https://issues.chromium.org/u/1/issues/<old id>)
- TODO(bugs.chromium.org/<old id>)
Bug id mapping is sourced from go/chrome-on-buganizer-prod-issues.
See go/crbug-todo-migration for details.
#crbug-todo-migration
Bug: b/321899722
Change-Id: Iee14d10d544e9f0ec046117cc4ec8a55c427adc0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5469947
Reviewed-by: Darryl James <dljames@chromium.org>
Owners-Override: Alison Gale <agale@chromium.org>
Commit-Queue: Alison Gale <agale@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1290838}
The canonical bug format is TODO(crbug.com/<id>). TODOs of the
following forms will all be migrated to the new format:
- TODO(crbug.com/<old id>)
- TODO(https://crbug.com/<old id>)
- TODO(crbug/<old id>)
- TODO(crbug/monorail/<old id>)
- TODO(<old id>)
- TODO(issues.chromium.org/<old id>)
- TODO(https://issues.chromium.org/<old id>)
- TODO(https://issues.chromium.org/u/1/issues/<old id>)
- TODO(bugs.chromium.org/<old id>)
Bug id mapping is sourced from go/chrome-on-buganizer-prod-issues.
See go/crbug-todo-migration for details.
#crbug-todo-migration
Bug: b/321899722
Change-Id: Ifd155bbeff882ea939f74cf8b8f847f42847940b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5468156
Reviewed-by: Darryl James <dljames@chromium.org>
Owners-Override: Alison Gale <agale@chromium.org>
Commit-Queue: Alison Gale <agale@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1290297}
Currently, the VrUiHost is intended to be created when a device runtime
is added, and will live as long as that runtime does. However, this adds
a lot of additional complexity to the VrUiHost's internal state. It also
leads to a somewhat weird lifetime management, where the
ChromeXrIntegrationClient is responsible for creating and maintaining a
separate reference to the VrUiHost code. Further, the plumbing to allow
a VrUiHost to be created only exists for the windows-specific
IsolatedXrDeviceProvider, meaning that to enable overlays on Android, we
have to find an alternate route for creating a VrUiHost.
This change moves the VrUiHost to be created/destroyed alongside the
session. This allows for simplifying some of the logic in the class
since it doesn't need to worry about existing across the span of
multiple sessions. This also removes the need for two of the
BrowserXRRuntime observer methods that it was subscribing to, as the
things they were used for can now be done during construction (via new
arguments) and destruction. The remaining BrowserXRRuntime observer
method that VrUiHostImpl used can simply be moved to the class
definition, since it was the only class that overrode that method. This
further contributes to simplifying the lifespan for the VrUiHostImpl.
Finally, since the VrUiHostImpl is now created alongside the session,
we no longer need the XRCompositorHost to provide the ImmersiveOverlay
to the session and can simply supply the ImmersiveOverlay directly when
creating the session.
This change also defines the VrUiHost base class and creation method for
all platforms, since future work in this area to enable Overlays on
Android will require that. There are still a couple of Windows-specific
things that the VrUiHostImpl and their children do (apart from simply
needing an Android-compatible GraphicsDelegate), so for the time being,
Chrome's actual implementation of that method is left to be basically
windows-specific. This will minimize the need for future changes, since
the BrowserXrRuntimeImpl will already need to handle the VrUiHost not
existing, since there are currently no plans to create one for every
runtime type (e.g. ARCore).
Bug: 40901055
Change-Id: I2bbb7b085c689eab6b4e8861d41b44aff627baeb
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5304598
Reviewed-by: Chris Bookholt <bookholt@chromium.org>
Reviewed-by: Piotr Bialecki <bialpio@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Auto-Submit: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1265368}
Improves the force-webxr-runtime logic in several ways:
1) Adds ArCore and Orientation Sensors as options
2) Removes lingering references to GVR
3) Removes some existing logic to not add enabled providers if another
runtime was forced. Enabled runtimes are always added. Disabled runtimes
are added if their runtime is enabled *or* force-webxr-runtime is set to
their runtime.
4) Centralizes Runtime forcing to xr_runtime_manager_impl.
One area of potenital future improvement would be to replace the
"SupportsArBlendMode" with just a "SupportedSessionModes" set, and then
we can have a flat list of items to check and can consolidate some of the
`Get(Mode)Runtime` logic; but that started to spiral into a larger CL
than seemed prudent for this change, and isn't really necessary longer
term.
Fixed: 1524157
Change-Id: I3707cd0fb8295e7baf15f33eb9545d682eeee303
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5277864
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Piotr Bialecki <bialpio@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1258251}
Attempts to create an XrInstance before creating an `OpenXrDevice` on
Android. This ensures that the OpenXr runtime can actually be supported
on the current device before we create the device that would attempt to
supply an OpenXr Session. This early creation of the XrInstance also
allows us to query for the supported environment blend modes at device
creation and allows us to accurately report if the device can support
a non-opaque blend mode, at which point it will take priority over
ARCore for "immersive-ar" sessions as well.
Note that initial plumbing of the service/webcontents was based on:
https://crrev.com/c/4632076
Bug: 1435548,1458584
Change-Id: Ibb8e04014c67da03cd9bab92f011901d2d88d607
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5146928
Reviewed-by: Brandon Jones <bajones@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1242227}
This is now the default for WebUI bindings, so setting true is
unnecessary. In this CL updating all uses within content/, docs/ and
ui/webui/examples/
Bug: 1002798
Change-Id: If2ab305c5b56524e5f2f4b4313c58ea664f9ad4b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5009906
Reviewed-by: Bo Liu <boliu@chromium.org>
Reviewed-by: Demetrios Papadopoulos <dpapad@chromium.org>
Commit-Queue: Rebekah Potter <rbpotter@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1222665}
Currently Viz allows only 1 HostFrameSinkClient to be bound to a
FrameSinkId for the lifetime of this ID. This client maps to the
RenderWidgetHostView for FrameSinkIds associated with a renderer side
compositor.
In order to reuse the compositor for a cross-RenderFrame navigation in
the renderer process, ownership of the FrameSinkId needs to be
transferred between RenderWidgetHostViews.
This change adds an API to register a HostFrameSinkClient in pending
state. This will be used by a speculative RenderWidgetHostView to claim
ownership of the FrameSinkId when the previous RenderWidgetHostView is
destroyed.
The model still allows only 1 HostFrameSinkClient to be registered at
a time. Since this API is only used for same-process cross-RFH
navigations, the old RenderWidgetHostView is guaranteed to be destroyed
before the new RenderWidgetHostView is made visible.
Bug: 1464791
Change-Id: Ib341afbf6f701c77f104a368dc394d33b805914e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4919436
Reviewed-by: Vladimir Levin <vmpstr@chromium.org>
Reviewed-by: ccameron chromium <ccameron@chromium.org>
Auto-Submit: Khushal Sagar <khushalsagar@chromium.org>
Reviewed-by: Bo Liu <boliu@chromium.org>
Reviewed-by: Kramer Ge <fangzhoug@chromium.org>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Commit-Queue: Bo Liu <boliu@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1209738}
This section provides information about:
1) Active Runtimes Table, including details such as the Device ID, Supported
Features, and AR Support.
2) Removed/Added Runtimes Table, including Device ID, Runtime State, and
Time. Added runtime rows also include Supported Features and AR Support.
Bug: 1488296
Change-Id: I3800c6ff38dc97ac7be5b4e952323c38b77b268b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4905373
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Commit-Queue: Mahmoud Tawfik <mahmoudaahmedd@gmail.com>
Cr-Commit-Position: refs/heads/main@{#1206573}
Extend the logging mechanism to include XR session rejections, XR
session starts, and XR session stops to offer insight into the complete
lifecycle of XR sessions, tracing their lifecycle from request to
rejection or from request start to stop, by capturing relevant events
and associating them with the respective trace IDs.
Change-Id: I6dac71447aa80dc29f0cf7e7d18d13353aa0697f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4818508
Commit-Queue: Mahmoud Tawfik <mahmoudaahmedd@gmail.com>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1203008}
Summary:
This commit introduces the implementation of XR Session section
within the WebXR Internals debugging page.
- XRSession Info: This section provides a display of information
regarding the XR session. It includes details such as requested time
along with trace id, mode, usage preferences,
data format preferences and a list of required/optional features.
Bug: 1458662
Change-Id: I9ae09f37185999ac8cbf2f5150fbf99a12755f86
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4793733
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Mahmoud Tawfik <mahmoudaahmedd@gmail.com>
Reviewed-by: Will Harris <wfh@chromium.org>
Reviewed-by: John Lee <johntlee@chromium.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1189308}
Summary:
This commit introduces the initial version of the WebXR Internals
debugging page. The page will display relevant information and data
for debugging purposes.
The following features have been implemented:
- Device Info: Displays information about the user's system,
including GPU driver, GPU vendor ID, operating system name and OS
version.
Further work is needed to complete the remaining attributes in the XR
Session Info section and integrate data fetching from the Blink module
for the interactive charts.
Bug: 1458661
Change-Id: I779cd91d568cc6466e37c893c7be7b2b38b75e7e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4395790
Reviewed-by: Charlie Reis <creis@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Mahmoud Tawfik <mahmoudaahmedd@gmail.com>
Reviewed-by: Demetrios Papadopoulos <dpapad@chromium.org>
Reviewed-by: Piotr Bialecki <bialpio@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1173594}
This strengthens/enforces the assumption that many Xr devices had been
operating under which is that they would not receive a RequestSession
call when they currently had an exclusive session our outstanding
session request. As the XrRuntimeManager is created by the first
VrServiceImpl and then kept alive by each subsequent VrServiceImpl it
(and therefore the connections to the devices via BrowserXrRuntime) is
effectively a singleton, and thus is situated to be able to
authoritatively answer whether there is a current outstanding
session request, and thus any new requests should be ignored.
Fixed: 1450707
Change-Id: I9806c1381f7c2d7419cc93adf7023cfa12d062fd
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4658833
Reviewed-by: Piotr Bialecki <bialpio@chromium.org>
Auto-Submit: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Piotr Bialecki <bialpio@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1166107}
