Closed Bug 1795325 Opened 2 years ago Closed 1 year ago

GPUProcess broke GeckoView WebXR support

Categories

(GeckoView :: Core, defect)

defect

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 1771854

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).

Component: Untriaged → WebVR
Product: Firefox → Core

Switching components as suggested by @jnicol in Matrix

Component: WebVR → Core
Product: Core → GeckoView

The severity field is not set for this bug.
:cpeterson, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(cpeterson)

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.

Status: UNCONFIRMED → RESOLVED
Closed: 1 year ago
Duplicate of bug: 1771854
Flags: needinfo?(cpeterson)
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.