playcanvas
Permissions policy violation: xr-spatial-tracking
If the document doesn't allow to use WebXR Device API, then a DOM exception is thrown:
Details: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Permissions-Policy/xr-spatial-tracking
Where do you get this error?
Windows Chrome? Maybe an iframe? Not sure what you are asking. Its a self-hosted environment. Noticed the error mentioned in our team and decided to add here. I can get the details if you clarify.
Repro: app.zip
npm install
node app.js
localhost:3000/printer
Additional details: https://www.w3.org/TR/permissions-policy-1/#document-policies
That's the same requirement as WebGPU .. needs to be https. I'll close this but please reopen if this is still a problem.
Please, reopen. The issue is not about HTTPS protocol. The issue is that the engine is trying to use WebXR Device API on a webpage that does not allow it, resulting in a permissions violation exception.
Changed the repro app, added local certs so https can be used. app.zip
https://localhost:3000/printer
Is this really something for the engine to handle? If you're going to host a WebXR app, then you're going to have to correctly configure your server.
The exception is thrown for a default blank application. The engine is using WebXR Device API regardless if the app is going to use WebXR or not. We don't use WebXR in any of our games, but still noticed the exception.
I get the same error twice. I'm embedding my viewer project with an iframe into a simple website. Everything https, no WebXR app: playcanvas-stable.min.js:9 [Violation] Permissions policy violation: xr-spatial-tracking is not allowed in this document. i._sessionSupportCheck @ playcanvas-stable.min.js:9 i._deviceAvailabilityCheck @ playcanvas-stable.min.js:9 :
Try adding these attributes to your iframes: allowvr="yes" allow="xr-spatial-tracking" allowfullscreen="yes" and ensure parent as well as child domains are in HTTPS.
By default, allowsFeature will return "self" for the xr-spcial-tracking, which is truthy. Unless the server explicitly forbids web xr on server side (which would stop web xr from working for both old and new users), I don't see how it can affect "all new users". I am closing this for the lack of interest/understanding and we'll patch it in our engine variant instead. Feel free to re-open.
By default, allowsFeature will return "self" for the xr-spcial-tracking, which is truthy. Unless the server explicitly forbids web xr on server side (which would stop web xr from working for both old and new users), I don't see how it can affect "all new users". I am closing this for the lack of interest/understanding and we'll patch it in our engine variant instead. Feel free to re-open.
Have you tested that properly, as MDN states otherwise:
Please note that Camera API might be restricted by the Permissions API, if the user did not grant the corresponding permission yet.
Please note that Camera API might be restricted by the Permissions API, if the user did not grant the corresponding permission yet.
I am not sure we are on the same page here. Permission policy is set by the server in the header of the webpage that it serves. Similar to cors and other headers that control the page. The user has no say in this. By default all features are permissive, so most users won't know about it or can decide if they want to enable/disable a feature on the client side once the page is loaded. He has the right to do so, stipulated by the server.
However, if the server forbids a feature, e.g. xr-spacial-tracking, then the web page will throw an error, since the user allowed to use it and the engine is trying to use it, but have no rights to do so.
When user has not visited an origin, first time XRSession is requested there is a permission popup, that asks if user want to grand permission to origin to run WebXR session. Based on docs, if such popup for the origin has not been asked yet, allowsFeature will return false (not granted). Which will lead to preemtevely stating that WebXR is not supported - which is wrong.
There are a couple things:
- "Support" of a feature by the browser is based on identifying if browser is capable of WebXR in the first place.
- "Availability" of a feature is when session has started identifying if a requested feature has been enabled and is available to be used.
What I would suggest, for granularity in between of "support" and "available" to provide "permitted".
But even then there are a couple of things to bear in mind:
- iframe without proper attribute - is one case.
- canvas without xr compatibility - is another case.
- lack of granted permission - is third thing.
And what is important, that allowsFeature does not indicate whether such permission is explicitly denied or it was not been asked yet at all.