Skip WebXR startup probe when xr-spatial-tracking is disallowed

[mvaligursky]

Suppresses the [Violation] Permissions policy violation: xr-spatial-tracking is not allowed in this document console warning that appears on startup for every app — even ones that never use XR.

Why:
AppBase always creates an XrManager (via pc.Application), and its constructor unconditionally probes WebXR by calling navigator.xr.isSessionSupported() for inline/VR/AR. When the document's permissions policy disallows xr-spatial-tracking (e.g. the app runs in an iframe without allow="xr-spatial-tracking"), the browser blocks that call and logs a policy violation — regardless of whether the project uses XR.

Changes:

• Gate the startup availability probe (and the devicechange listener) on a new private XrManager._allowsSpatialTracking() check.
• Only skip the probe when the Feature Policy API reports the feature is explicitly disallowed. When the API is unavailable (e.g. Safari / visionOS, where navigator.xr exists but document.featurePolicy does not) we cannot tell, so we proceed as before — avoiding a regression on those platforms.
• When skipped, emit a Debug.warn (debug builds only) explaining the cause and how to fix it (iframe allow attribute / Permissions-Policy header).

No public API changes.

[github-actions]

Build size report

This PR changes the size of the minified bundles.

Bundle	Minified	Gzip	Brotli
playcanvas.min.js	2261.9 KB (+0.2 KB, +0.01%)	581.9 KB (+0.1 KB, +0.01%)	452.3 KB (+0.3 KB, +0.06%)
playcanvas.min.mjs	2259.3 KB (+0.2 KB, +0.01%)	581.0 KB (+0.1 KB, +0.01%)	451.8 KB (−0.3 KB, −0.07%)

[LeXXik]

Didn't we close my fix for this previously?
#7029

[mvaligursky]

@Maksims — this PR revisits the approach from #7029, which you closed with this concern:

I believe this will break access to WebXR features for users that have not yet granted permission for it per origin. As allowsFeature returns false if it was either denied or were not requested by origin (by default it will false). [...] So this PR will break WebXR for pretty much all new users.

I've dug into this and I don't think that breakage actually occurs. I think the concern conflates two distinct mechanisms:

1. Permissions Policy (document.featurePolicy.allowsFeature('xr-spatial-tracking')) — a document-level policy set by HTTP Permissions-Policy headers and iframe allow attributes. Per the spec, xr-spatial-tracking's default allowlist is self, so on a normal top-level same-origin page allowsFeature(...) returns true. It is not false by default, and it is not per-user. It returns false only in cross-origin iframes or where a header / allow attribute explicitly restricts it.

2. Permission grant (the user-facing "Allow" prompt) — a separate mechanism, evaluated at requestSession() time, not at allowsFeature() time. Nothing here reads or depends on whether the user has previously granted XR per origin.

So for the overwhelming majority of PlayCanvas apps (top-level pages), allowsFeature is true, the probe runs exactly as before, and new users are unaffected.

The gate only returns false in restricted contexts (cross-origin iframe, or explicit policy). And in exactly those contexts, the spec says xr-spatial-tracking also governs whether "navigator.xr.requestSession() can return an XRSession that requires spatial tracking and whether the user agent can indicate support." In other words, when the policy disallows the feature, isSessionSupported() cannot report true and requestSession() would fail regardless — so skipping the probe loses no functionality. It only suppresses the [Violation] Permissions policy violation: xr-spatial-tracking is not allowed in this document console warning for a call that was already going to resolve false.

Two refinements over #7029 worth noting:

• We skip only on explicit disallow. When the Feature Policy API is unavailable (e.g. Safari / visionOS, where navigator.xr exists but document.featurePolicy does not), we proceed exactly as today — so there's no regression on platforms without the API.
• When skipped, we emit a Debug.warn (debug builds only) explaining the cause and the fix, so the behavior is visible rather than silent.

Happy to be corrected if there's a browser quirk I'm missing here — but based on the spec and the default self allowlist, I don't think this regresses WebXR for new users. Does this address the original concern?

References:

• MDN: Permissions-Policy: xr-spatial-tracking (default allowlist self)
• W3C Permissions Policy