From @brianchirls on August 9, 2017 16:18
In the 1.1 spec, there is a vrdisplayactivate event that seems to be fired when the headset (at least the Rift/Gear, but not currently the Vive) is placed on a user head. This can be used to automatically trigger presentation.
I don't see an equivalent even in the 2.0 spec, though there is a deactivate event - can someone tell me why this event doesn't exist? It seems pointless to have an event for taking the headset off but not one for putting it on.
Anyway, I ran into a case with the 1.1 spec as currently implemented in Firefox and Chromium that could be a problem. If two windows/tabs are currently open, it seems the event fires in all tabs, causing whichever tab (non-deterministically) gets the event first to request presentation. I think the spec should at least make a suggestion how this may be handled.
For example, I would prioritize whichever tab has focus. Then, if no tabs have focus, whichever tab is most in the foreground and then finally whichever tab is (most recently?) visible. Tabs that are hidden should maybe not receive the event until they become un-hidden (i.e. after document.onvisibilitychange fires).
Browser vendors and/or the community also need to consider whether/when a tab receives the event if another tab is presenting. e.g. let's say one tab is presenting, but the desktop user minimizes the presenting tab and focuses another one. Then, let's say the presenting tab stops presenting. So does the focused tab receive an activate event?
Copied from original issue: immersive-web/webxr#277
From @brianchirls on August 9, 2017 16:18
In the 1.1 spec, there is a
vrdisplayactivateevent that seems to be fired when the headset (at least the Rift/Gear, but not currently the Vive) is placed on a user head. This can be used to automatically trigger presentation.I don't see an equivalent even in the 2.0 spec, though there is a
deactivateevent - can someone tell me why this event doesn't exist? It seems pointless to have an event for taking the headset off but not one for putting it on.Anyway, I ran into a case with the 1.1 spec as currently implemented in Firefox and Chromium that could be a problem. If two windows/tabs are currently open, it seems the event fires in all tabs, causing whichever tab (non-deterministically) gets the event first to request presentation. I think the spec should at least make a suggestion how this may be handled.
For example, I would prioritize whichever tab has focus. Then, if no tabs have focus, whichever tab is most in the foreground and then finally whichever tab is (most recently?) visible. Tabs that are hidden should maybe not receive the event until they become un-hidden (i.e. after
document.onvisibilitychangefires).Browser vendors and/or the community also need to consider whether/when a tab receives the event if another tab is presenting. e.g. let's say one tab is presenting, but the desktop user minimizes the presenting tab and focuses another one. Then, let's say the presenting tab stops presenting. So does the focused tab receive an activate event?
Copied from original issue: immersive-web/webxr#277