@yihuds can you send me a small sample to reproduce the issue? or can it be reproduced on the samples in the repo?

Should we delete the value set in getSecureAbove22Preferences when logging out of FxA? I'm thinking on the use case of sharing a device with multiple people and see if there are secutity implications

@cabanier yes, it's a different implementation. It's a long story, but Mozilla has two browser engines that are used in VR projects: Servo and Gecko/Firefox. I'm working on the Gecko implementation, which is the one used for Firefox Reality shipped on Oculus Quest/Go devices.

The spec looks good so far. I haven't read all the discussions, maybe it has been already commented: on a high level the only thing I miss would be a separation between a layer and the surface/texture (as OculusVR/OpenXR do with SwapChains). But that separation might not be a friendly web pattern. Example of a use case: In Firefox Reality frontend we used that separation to dynamically switch between a flat (Quad Layer) and curved (Cylinder Layer) window without recreating or painting to a different surface, so the switch is super fast. With WebXR Layers you would need to render to different textures.

I'm implementing WebXR Layers in Firefox Reality and found this part of the spec confusing:

• Layers of type XRProjectionLayer MUST always be supported, regardless if the feature descriptor was requested.
• UpdateRenderState: if the layers array was passed and the session was not created with "layers" enabled, throw a NotSupportedError and abort these steps.

According to both statements the XRProjectionLayers can be created if the "layers" feature is not requested but can't be passed in the UpdateRenderState layers array if the layers feature is not enabled. So they are created for nothing.

We need to make this more clear in the spec. I guess the intended behavior is: "if the layers array contains any XRLayer that is not a XRProjectionLayer or a XRWebGLLayer and the the was not created with "layers" enabled, throw a NotSupportedError and abort these steps"

Fixes #3744

[Affected Versions]:

• Firefox Reality version 12-142112200 (acf8dec).

[Affected Platforms]:

• Oculus Quest - Android 7.1.1
• HTC Vive Focus - Android 7.1.2

[Prerequisites]:

• The Firefox Reality browser is open.

[Steps to reproduce]:

1. Navigate to https://www.ezdrm.com/html/drm-demos.asp
2. Play the demo from the page.
3. Observe the behavior.

[Expected results]:

• The video is played and DRM content is recognized on the page.

[Actual results]:

• The video is not played and the DRM related pop-up/prompt are not displayed.

[Notes]:

• Attached is a screen recording of the issue:
  • Screen Recording: link.

Fixes #3761

Fixes #3743

[Affected Versions]:

• Firefox Reality version 12-142112200 (acf8dec5)

[Affected Platforms]:

• HTC Vive Focus - Android 7.1.2
• HTC Vive Focus Plus - Android 7.1.2

[Prerequisites]:

• The Firefox Reality browser is closed.

[Steps to reproduce]:

1. Navigate to a normal video on YouTube and enter theater/full screen mode.
2. Observe the controllers.

[Expected results]:

• The controllers disappear.

[Actual results]:

• The controllers remain displayed.

[Notes]:

• Pressing the trigger button or the touchpad displays/hides the mini controls, but the controllers remain displayed.
• Attached a screen recording of the issue here.

Fixes #3724

Last step in migrating FirefoxReality l10n to the main branch.

ok, it can only be done for debuggable builds which is not the case of Taskcluster.

We should use != instead of for downgrades

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: WebXR Layers API
• Specification or proposal URL: https://immersive-web.github.io/layers/
• Caniuse.com URL (optional):
• Bugzilla URL (optional): https://bugzilla.mozilla.org/show_bug.cgi?id=1652709
• Mozillians who can provide input (optional): @kearwood, @daoshengmu, @Manishearth @larsbergstrom, @thomasmo, @jdashg, @bluemarvin

Other information

The spec adds support for composition layers to the WebXR spec. Composition layers have many benefits:

• Improved Performance and judder.
• Better Legibility/visual fidelity for elements such as text, UI, video, quads, cubemaps.
• Reduced Latency and Power consumption

WebXR Layers, specifically XRProjectionLayer, will also enable a better render path for our gecko WebXR implementation:

• Proper way to implement WebXR msaa. We disabled msaa in the current WebXR implementation because the OpaqueFBO approach exposed in WebXR API is not totally compatible with the path forward from the WebGL team. This is causing Firefox to have worse VR quality than other browsers. We need the XRProjectionLayer render path to enable msaa for the users.
• Proper way to enable multiview. Multiview is exposed in WebGL but it requires several copies and conversions from texture to side-by-side textures in the render path to be connected to WebXR. By using the texture-arrays approach provided in the XRProjectionLayer we can implement multiview with less surface blits and conversions, which are specially slow on mobile. This will help with to improve the WebXR performance.

Regarding privacy or fingerprinting I think it's a pretty safe API. I don't think it exposes anything new that is not already exposed in WebXR and WebGL. The only thing I see is knowing if a device supports compositor layers or not. Our initial plan is to implement the XRPRojectionLayer subset, which is always guaranteed to be supported, so not a problem for that use case. For the other layers, if we consider detecting the layers feature a problem, we could always mark them as supported and just fallback to geometry, reusing the code we already have in the external browser apps (Note: We wouldn't need to add that fallback geometry code to WebXR/WebGL in Gecko. It would be just responsible for sharing the layer info on the SubmitFrame calls, not creating the final fallback geometry).

Tag Review thread