"focus"/"blur" naming on XRSession may be confusing

[thetuvix]

The naming of the "focus" and "blur" events on XRSession are somewhat confusing to me.

I hadn't thought about those events for a bit and when I saw them today in the spec, I presumed they were telling the app when it could expect or not expect to receive XR input updates such as pose updates, select events and other input source button presses. Basically, I presumed these events to be the equivalent of "focus"/"blur" in the core DOM. However, these events actually tell the app when its pixels are invisible or visible, allowing it to save effort by pausing its rendering.

While it is likely that XR input will also be removed from the app during the example situation of a sensitive overlay being displayed, that seems like a secondary effect. Specifically, if XR input is removed from the page temporarily due to a non-sensitive partial overlay, the UA would expect the page to continue rendering. However, it's unlikely that a UA could raise the "blur" event to communicate the loss of input, since we'd have already suggested that pages stop rendering when they receive that event.

This seems more similar to the Page Visibility API and its visibilitychange event, which serves an equivalent purpose for 2D content, letting the page know when the user can't see it, allowing the page to stop expensive rendering or pause content. Perhaps a single visibilitychange event better fits our intended developer mental model here?

[thetuvix]

Another hint that a name may be off is when we consistently use some word in prose to describe a concept, but then use a different token for that concept in the IDL.

The explainer section that describes these events talks about "suspended sessions" and then uses the terms "suspend"/"suspension" many times. Another option would be to rename these events "suspend" and "resume".

My primary concern with that option is that "suspend" seems too strong given the description of how UAs would behave - I don't personally think of a suspended session as one where the app can still get device state, but just more slowly. The primary qualitative thing going on here is that the user can no longer see the app's pixels, and so "visibilitychanged" still seems more correct. However, in that case, perhaps we should adjust the prose too to refer to "invisible sessions".

[thetuvix]

Oops, clicked the wrong comment button 😄

[kearwood]

In a future beyond having only XRWebGLLayers, we may have XRLayer types (eg quad floating in space) that are asynchronously rendered by the UA. In this case, there would be no need to submit new frames or even have a RAF loop active for the content to continue to be projected and rendered correctly. Such XRLayer types could be considered safe for use when compositing content from multiple origins or while system dialogues are visible, as the UA could visually indicate the layer with input focus and accept user input without leaking information about the user's head pose to the content supplying the blurred XRSession.

While only having XRWebGLLayers, inherently requiring exclusive mode presentations, there may be confusion between the concepts of "visibility" and "focus", as they would be treated equivalently. I would suggest considering potential of future non-exclusive XRSession interaction before losing "blur" and "focus". Perhaps there are scenarios where an independent "suspend" and "resume" state would be beneficial?