GPUProcess broke GeckoView WebXR support
Categories
(GeckoView :: Core, defect)
Tracking
(Not tracked)
People
(Reporter: svillar, Unassigned)
Details
Steps to reproduce:
We use GeckoView interface in Wolvic browser. GPU process does not support WebXR sessions properly because it does not inherit the external context that is set in the web content process (is that the name in Gecko?) via the API GeckoVRManager:setExternalContext().
In order to give a little bit more context, one of the first things done by the WebXR implementation is to enumerate the XR devices (generally as a response to isSessionSupported() JS call by developers). This means calling VRManager::enumerateDevices(). This eventually results in VRManager::ProcessManagerState_Idle_StartEnumeration() being called. As it can be seen, for the case of Android...
#if defined(MOZ_WIDGET_ANDROID)
// In Android, we need to make sure calling
// GeckoVRManager::SetExternalContext() from an external VR service
// before doing enumeration.
if (!mShmem->GetExternalShmem()) {
mShmem->CreateShMemForAndroid();
}
if (mShmem->GetExternalShmem()) {
mState = VRManagerState::Enumeration;
} else {
// Not connected to shmem, so no devices to enumerate.
mDisplayInfo.Clear();
DispatchVRDisplayInfoUpdate();
}
#else
the code basically checks whether the shared memory structure used to communicate with the external provider of VR data was created or not. And if we check the implementation of VRShmem we find this
void VRShMem::CreateShMemForAndroid() {
#if defined(MOZ_WIDGET_ANDROID) && defined(MOZILLA_INTERNAL_API)
mExternalShmem =
(VRExternalShmem*)mozilla::GeckoVRManager::GetExternalContext();
if (!mExternalShmem) {
return;
} else {
mIsSharedExternalShmem = true;
}
Basically if we don't have access to the external context of the VRManager the code bails out and reports that there are no devices connected. The problem is that this external context was set on the web content process (again not sure about the name) but there is no code setting that in the GPU process, so the GPU process will always report that there are not devices connected and thus that WebXR is not available.
I reported this a while ago in https://bugzilla.mozilla.org/show_bug.cgi?id=1771854 but I have decided to report it again now with more data, as I found some time to debug the issue a bit. Note that contrary to what is mentioned in the other bug this is about an active API (WebXR) and not about a deprecated one (WebVR).
Reporter | ||
Updated•2 years ago
|
Reporter | ||
Comment 1•2 years ago
|
||
Switching components as suggested by @jnicol in Matrix
Comment 2•2 years ago
|
||
The severity field is not set for this bug.
:cpeterson, could you have a look please?
For more information, please visit auto_nag documentation.
Comment 3•1 year ago
|
||
Closing this bug as a duplicate of bug 1771854.
We may develop WebXR at some point, but currently it is not on a roadmap. If and when we do, we'll likely resurrect some of these wontfix bugs.
Also, contributors are welcome to work on this area of the code if they like. I'm sure we can find the bandwidth to do reviews.
Description
•