Backgrounded Tabs and WebXR

[AdaRoseCannon]

The default assumption for WebXR is an external dumb display connected to an external computer which still displays the browser and handles the rendering. When the user enters WebXR the page continues rendering as usual.

/facetoface All-in-one devices such as the Apple Vision Pro and Meta Quest hide the browser to focus rendering resources on the WebXR content. As part of hiding the browser the page itself still has to sort-of run as some content needs to be updated but other content does not update. I don’t think it is specced out anywhere which bits keep running and which bits don’t but to ensure cross compatibility we should establish this somewhere.

Here are some examples of the buckets and examples of things in each:

Things which should keep working:

• Video
• Audio
• gamepad
• Input elements and associated events

Things which definitely should not work:

• The page’s rAF

Things that are a maybe:

• Resize observer
• The page updating layout??
• CSS animations and transitions

[KooIaIa]

When you say tabs - do you mean the page that opened WebXR or all other pages? This seems most critical for the page that the WebXR user is currently in.

Is running in the background towards the goal of being able to access a webpage in WebXR in the foreground? For example, a webpage running in the background on a PC can do screen capture to put itself on a texture and make itself visible in WebXR. Being able to render in the background is really good.

The best possible situation seems like being able to view it in the foreground in real WebXR. Once we can do that in browsers, I think these background expectation will hold stronger too.

Spec'ing that webpages should still be expected to be able to be fully functional webpages with WebXR is a good expectation to set.

[m-blix]

Similar previous issue: #1317

[hybridherbst]

I'd be curious what the relationship is to dom-overlay; it feels like there should be a (specification) relation here.