Various changes around null and emulated poses

[Manishearth]

This contains changes to:

• Allow poses to be null in more situations (fixes Allow poses to be null in more situations #1042)
• Force emulation in getViewerPose(), making it not possible to return null poses, and delay requestReferenceSpace() until tracking has been established. (Should requestReferenceSpace() wait until getViewerPose() won't be null? #674)
• Reintroduce check for current global object in pose security check (removed in Removed use of responsible and active and focused documents #1030)
• Make it so that the document visibility check can suppress poses without throwing an exception. Exceptions are for cases where the user's code is incorrect, not when stuff unpredictably changed from underneath the user. (partially addresses Reporting pose data depends on the state of the document? #1041)
• Some spec language cleanups around reference space creation

For users, the main change here is that requestReferenceSpace() might have some delay involved in resolving the promise, but on the plus side getViewerPose() will never be null.

---

Preview | Diff

[Manishearth]

/agenda to discuss the changes being made here

[Manishearth]

In the call today there seemed to be general consensus around allowing getPose() to be null for arbitrary spaces.

It was pointed out that for handheld input controllers we may wish to encourage them to never return null when the input source is active and instead trigger oninputsourceschange events. (Worth noting, you can still hold on to a reference to an old input source's space, and that should definitely return null in getPose()). I could potentially add language to that effect somewhere, though I'd rather wait for @toji to get in an initial review.

The point about getViewerPose() did not get discussed as much, however this PR fixes the main issues that caused contention in #674, so it feels like that change is fine.

[alcooper91]

I thought in a previous call the resolution for #674 that was discussed was to not enforce any particular behavior and to leave that to be a UA choice? (Relevant Minutes: https://www.w3.org/2020/05/12-immersive-web-minutes.html)

[Manishearth]

Hmm, you're right. However, I think neither I nor @toji had a strong opinion on that, and my opinion has shifted towards Alex's original one of "getViewerPose() should never be null" now that getPose() is much more free to be null. The reason I felt that getViewerPose() should be allowed to be null was really that I felt that "populate a pose" should be null in more situations so that getPose() can be null.

cc @thetuvix

If you or others feel strongly I can revert that bit.

[toji]

Sorry it's taken me a while to comment on this. Wanted to hear the call discussion and then come back. I'm OK with everything here with the exception of blocking requestReferenceSpace() resolves so that getViewerPose() is never null. (That said, I do like the forced emulation bit once tracking have been established.)

My biggest concern is that a very common pattern in many apps is to wait for a reference space before spinning up the rAF loop, but in many cases the device will have already switched over to presenting the session's content as soon as the session is created. If there's a need for some action on the user's part to help establish tracking (as is commonly the case for mobile AR, where you want to wiggle your phone around) then having that rAF loop available as a point to ping the tracking state is useful, as well as offering a logical place to draw any helper dialogs with a more reliable (viewer?) space.

[Manishearth]

Oh, that's a fair point. I'll remove those changes and fix up the rest of the PR. You should leave a comment to that effect on the other issue, and perhaps we should reagenda it.

[toji]

LGTM. Thanks!

[Manishearth]

@toji oh, I also added a note about hand controllers losing tracking, as discussed in the call. want to quickly check that as well?

[toji]

Controller comment LGTM too!

[Manishearth]

Going to merge, the only part of this PR that was not discussed fully in the call was the one I removed.