Repository navigation
Reporting pose data depends on the state of the document? #1041
Description
In https://immersive-web.github.io/webxr/#protect-poses there's a per-frame check based on the document associated with the session. This seems like it may have unexpected UX consequences, as the user is no longer interacting with that document, since they have a headset on.
Activity
asajeffrey commentedon May 15, 2020
This came up in #1030, in conversation with @Manishearth
asajeffrey commentedon May 15, 2020
As an example,
magazine.commight have an advert fromcar-manufacturer.comwith VR content (which the magazine cam bless as a feature on theiframecontaining the ad). If the user enters the ad, but while they're in the headset, accidentally clicks or scrolls away from the advert, the pose data will stop being reported.Manishearth commentedon May 15, 2020
cc @avadacatavra
/agenda for discussions of security implications
Manishearth commentedon May 15, 2020
I'm also a bit uneasy about this throwing a SecurityError, i'd rather it make the pose null. See #1042 for more discussion about that.
Manishearth commentedon May 18, 2020
Related: #1042
avadacatavra commentedon May 18, 2020
@Manishearth can you elaborate on why you're uneasy about throwing a Security Error?
Manishearth commentedon May 18, 2020
@avadacatavra I'm totally for throwing the security error in some of the cases there.
In general for web specs errors should be thrown in cases where the application did something wrong (and thus, should only be thrown in cases which are preventable). In other words, if an error is being thrown, the user should be able to restructure their code to avoid it.
This is possible for the case when realms don't match ("don't call
iframe.contentWindow.currentFrame.getPose()"), but the other cases are unpredictable. It's possible to have a race condition with the "hidden" state, and it's not possible at all to handle this focus condition well. Throwing a security error when the user switches focus seems wrong because we're telling the author that "they did something wrong", but the user switching focus is not something the author can easily detect so there is no better thing to do here.This is why I think a null pose instead of an error makes sense. Null pose means "no pose for you", an error means "you did something wrong, please fix it".
Manishearth commentedon May 22, 2020
This is fixed in #1058 : the document being hidden causes webxr to report null or emulated (cached) poses.
asajeffrey commentedon May 22, 2020
Where "this" is returning null rather than throwing an exception, not the original issue that I don't think we should be doing this check at all!
Manishearth commentedon May 22, 2020
alright, udpated the PR to not close this issue
Manishearth commentedon May 26, 2020
There seems to be general consensus that we can return
nullhere instead of throwing an exception.This does not handle the UX issue of unexpectedly tabbing out.
Manishearth commentedon May 26, 2020
There seems to also be general leaning towards a feeling that this check is unnecessary, and that
visibilityState(which we already handle) should be enough here.I'm going to keep the changes in #1058 that replace the
SecurityErrorwith anull, but after that lands I can open a PR that removes that language altogether where the final discussion can be had.Manishearth commentedon May 29, 2020
With #1058 the check is no longer an error. I'll open a PR for removing it entirely or making it a bit more UA-dependant.
Manishearth commentedon May 29, 2020
Opened #1067 to make this UA-choice. Also open to removing it entirely
asajeffrey commentedon May 29, 2020
I'd prefer just removing this check altogether unsurprisingly.