search

immersive-web / webxr-polyfill

Use the WebXR Device API today, providing fallbacks to native WebVR 1.1 and Cardboard
Apache License 2.0
386 stars 86 forks source link

VRDisplay.requestPresent is rejected #45

Open jfcampos opened 5 years ago

jfcampos commented 5 years ago

Complete error: WEBVR22602: VRDisplay.requestPresent is rejected - presenting HTMLCanvasElement's context is not compatible with the VRDisplay. Event.preventDefault() must be called during the firing of webglcontextlost event on the presenting HTMLCanvasElement.

Edge 42.17134.1.0 Microsoft EdgeHTML 17.17134 Windows 10 1803 Build 17134.407

polyfill samples don't work (webVR works), we had it only in that pc (others work fine), any hints of what's causing the issue?

jsantell commented 5 years ago

@jfcampos is this with the latest release? that shouldn't change anything AFAIK, but just to make sure.

Per WebVR 1.1 spec:

In order for a WebGL canvas to be used as a VRSource, the context MUST be compatible with the VRDisplay. This can mean different things for different environments - for example, on a desktop computer, this means that the context MUST be created against the graphics adapter that the VRDisplay is physically plugged into. In the event that a context is not already compatible with the VRDisplay, while the requestPresent promise is outstanding, the context will be lost and attempt to recreate itself using the compatible graphics adapter. It is the document’s responsibility to handle WebGL context loss properly, calling preventDefault() during webglcontextlost and recreating any necessary WebGL resources during the webglcontextrestored event. If the webglcontextlost event is fired but preventDefault is not called, the requestPresent() promise MUST be rejected. If the User Agent requests user consent in response to requestPresent(), the context-lost operation MUST NOT happen prior to the user’s granting consent. If the context-lost event is handled, all other WebGL contexts on the page MAY also have their context lost as byproduct of using the correct graphics adapter instead of the default one. The promise may also fail for a variety of other reasons, such as the context being actively used by a different, incompatible VRDisplay. The fulfillment of the requestPresent() promise implies that the WebGL context is now compatible with the VRDisplay.

No context loss is handled in the polyfill. Is this occurring during the second requestPresent, like the Oculus issue in #41? I found this mentioned in a PlayCanvas issue.