Should getViewport return null if there is no matching viewport?

[asajeffrey]

The spec at https://immersive-web.github.io/webxr/#dom-xrwebgllayer-getviewport says "Let glViewport be the WebGL viewport from the list of viewports associated with view," burt doesn't say what to if there isn't one. Should there be text "If there is no such viewport, return null."?

[toji]

So in general if you can't produce a valid viewport for a given XRView then you shouldn't be reporting that XRView in the first place. There's no practical use for a view that cannot be rendered, and as such a view without a corresponding viewport is not a thing the spec anticipates. (Note that the viewport is a layer-specific concept, and some future layers may not have need for viewports at all, or have an alternative way of associating a view with a renderable area. Regardless of approach, however, there must always be a way to map a view to the thing that it needs to render into.)

That said, this DID highlight a different but related inconsistency for us while reviewing it. In the algorithm for getViewport we indicated that if the view was from a different XRSession than the layer then the function should return null, but elsewhere in the spec for the same class of error we throw an InvalidStateError, which seems like a more fitting response to what is clearly an invalid call. Posted #771 to normalize that behavior. Thanks!

[asajeffrey]

Oh I see, if a device changes which views are available, then its expected to restart the session? So the list of views for a given session is immutable?

[toji]

No, the list of views may change between frames and the app is expected to iterate through the list of views on a per frame basis.

But now I see where you're coming from. If the app holds a reference to a view and the view configuration switches mid-session so that the old view is no longer active then it won't have a viewport associated with it any longer, but may still be passed into this function. We should probably throw an InvalidStateError in that situation as well.

Thanks for bringing that to our attention!

[Manishearth]

fixed in #796