Reporting pose data depends on the state of the document?

[asajeffrey]

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.

[asajeffrey]

This came up in #1030, in conversation with @Manishearth

[asajeffrey]

As an example, magazine.com might have an advert from car-manufacturer.com with VR content (which the magazine cam bless as a feature on the iframe containing 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]

cc @avadacatavra

/agenda for discussions of security implications

[Manishearth]

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]

Related: #1042

[avadacatavra]

@Manishearth can you elaborate on why you're uneasy about throwing a Security Error?

[Manishearth]

@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]

This is fixed in #1058 : the document being hidden causes webxr to report null or emulated (cached) poses.

[asajeffrey]

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]

alright, udpated the PR to not close this issue

[Manishearth]

There seems to be general consensus that we can return null here instead of throwing an exception.

This does not handle the UX issue of unexpectedly tabbing out.

[Manishearth]

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 SecurityError with a null, but after that lands I can open a PR that removes that language altogether where the final discussion can be had.

[Manishearth]

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.