Third-party app iframe omits accelerometer/gyroscope/magnetometer — DeviceOrientation unusable (WebKit supports this since r273444)

[freeandpositive11-design]

Summary
Third-party Pi apps are framed with an allow attribute that omits accelerometer, gyroscope and magnetometer. WebKit gates device orientation on those features, so DeviceOrientationEvent.requestPermission() resolves as "denied" immediately and the user is never prompted. A compass is therefore impossible inside Pi Browser on iOS.

Request
Add accelerometer; gyroscope; magnetometer to the allow list used for third-party apps.

All three are required. Per WebKit bug 221399 comment 47, devicemotion needs accelerometer and gyroscope, while deviceorientation additionally needs magnetometer. Adding only gyroscope will not fix the compass. Worth noting: the Pi partner frame currently lists accelerometer and gyroscope but not magnetometer, so it would hit the same wall.

This is known to work in WebKit
WebKit bug 221399 ("Device motion / orientation events not working in third-party iframes despite Feature-Policy allowing it") is RESOLVED FIXED, landed as commit r273444. Before that change WebKit refused the API in third-party iframes outright; afterwards it honours the allow attribute. Bug 152299 was closed as a duplicate of it.

Precedent: Google Colab received the same request in colabtools issue #1704, for the same reason — a platform that frames third-party content and had omitted sensor features from its allow attribute.

What I found in the production bundle
In app-cdn.minepi.com/static/js/main.f8d0af10.js there are three hardcoded allow lists:

1. Pi partner frame: accelerometer; autoplay; camera; gyroscope; payment; microphone
2. Ecosystem directory: clipboard-read; clipboard-write; camera; geolocation
3. Third-party apps: clipboard-read; clipboard-write; camera; geolocation; microphone; web-share

Measured behaviour (iPhone, iOS 18.7, PiBrowser 1.17.1)

Mode	Framed	requestPermission	Orientation events
Opened from Pi app list	yes (parent app-cdn.minepi.com)	denied, no prompt	0
Opened top-level by typing the URL	no	granted	232 events, heading 154 degrees
Safari via Pi.openUrlInSystemBrowser()	no	granted	147 events, heading 149 degrees

Same device, same code, same day. Only the frame differs.

Workarounds I verified do NOT exist

• Permissions-Policy / Feature-Policy headers on the app's own server. A frame can only drop inherited permissions, never add them.
• Nesting a further iframe, or loading from another origin. Policy is inherited downward.
• Generic Sensor API (Magnetometer, AbsoluteOrientationSensor). Not implemented in iOS WebKit.
• deviceorientationabsolute instead of deviceorientation, and event.absolute. Same API, same policy.
• The native bridge. I went through all message types in the wrapper; none relate to orientation, motion or compass.
• Pi.requestPermission(). The whitelist in the wrapper is limited to camera.
• PiNet (*.pinet.com). Same allow list, and the native bridge is refused there.
• Android. Loads the identical bundle with the identical list.

Also worth flagging: WebKit's behaviour here is indistinguishable from a user denial, so an app cannot detect the situation and degrade gracefully — this was raised in comment 2 of the WebKit bug and is still true from the app's side.

Privacy impact: none. iOS still presents its own permission prompt and the user still has to accept. The current policy does not protect the user; it removes their ability to accept.

Impact: qibla direction is a daily need for a very large share of Pioneers, and a compass is the expected interface for it. The same change enables navigation, stargazing and AR apps ecosystem-wide.

Happy to test on Testnet and report results.

[Patrik / freeandpositive11 / Pi network acound: Sen141]
[Waktu]