Bug 254863

<rdar://problem/107512442>

Thanks for the photos, Klaus. That's really helpful. We will take a look if we align with the W3C spec (or if the spec is wrong, we can fix that too!). This is be a notoriously difficult thing to get right... even different versions of Android have disagreed, including other browsers on Android. If possible, can you also check what Firefox reports?

Using https://krpano.com/ios/bugs/ios164-screen-orientation/ Firefox Nightly 113 Android 13 window.orientation: -90 screen.orientation.angle: 270 correct screen.orientation.type: landscape-primary screen.orientation.type (parsed): 90 wrong Chrome Canary 113 Android 13 window.orientation: -90 screen.orientation.angle: 270 correct screen.orientation.type: landscape-secondary screen.orientation.type (parsed): -90 correct Safari 16.4 iOS 16.4 window.orientation: -90 screen.orientation.angle: 90 wrong screen.orientation.type: landscape-primary screen.orientation.type (parsed): 90 wrong

oh, wonderful! Thanks for doing that, Karl. 🙏

@Karl Dubost I'm surprised by your Firefox Android results - what device was that? All my Android test-devices (many) were reporting 'screen.orientation.type' the same way as Chrome and matching to the 'screen.orientation.angle' value so far... But anyway, even there the 'angle' value is the same and that's probably the more important one. The interpretation of 'type' and what is primary/secondary is arbitrarily, although it would be nice if the specs could chose one interpretation here. I have added two more screenshots from Android devices with Firefox-Nightly here: https://krpano.com/ios/bugs/ios164-screen-orientation/ And the testcase now also prints the user-agent for easier checking.

Created attachment 465768 [details] Firefox-nightly-113-pixel-7 This is the result with a pixel 7

Hmm... so, the spec says: https://www.w3.org/TR/screen-orientation/#dfn-screen-orientation-values-table If you have the phone facing you upright ("portrait natural"), and you turn it right 90deg, it should return "angle 90 or angle 270" (not -90). In fact, I don't think the spec ever says to return a negative number for the angle, as that would be weird. That's enforced by the "unsigned short": ``` readonly attribute unsigned short angle; ``` I think Webkit is right and Firefox and Chrome are wrong here.

so yeah, rechecking in the simulator, we are "doing it right"™️. Device held up right: 0, portrait-primary Device rotated to the right (notch on the right): 90, landscape-primary Device rotated to the left (notch on the left): 270, landscape-secondary Same with the conformance tests on WPT - they only check positive integers and have done so for 5+ years: https://github.com/web-platform-tests/wpt/blob/master/screen-orientation/orientation-reading.html

Marking as invalid as WebKit is following the spec here. Hopefully the engines will update to return the correct values per the spec (or, at least, hopefully they can propose the change to the standard if there is some valid reason to so).

Hmm... that means maybe in future either the specs and then Safari or Chrome&Firefox could change...? This unfortunately leaves this API in a broken state for the moment, as it is not usable without browser-detection and also because it might break in the future. So for the moment it could be said that it's better to use the deprecated window.orientation instead? At least this one seems to be currently the same in all browsers...

(In reply to Klaus Reinfeld from comment #10) > Hmm... that means maybe in future either the specs and then Safari or > Chrome&Firefox could change...? I’ll raise this over at the W3C and see if we can again get consensus. I know the Firefox folks were updating their implementation so hopefully we can convince them to align with us. I’ll see if I can also get someone from Chromium to weigh in. > This unfortunately leaves this API in a broken state for the moment, as it > is not usable without browser-detection and also because it might break in > the future. Yeah. Sadly angle has always been super unreliable. I wish we would’ve added it to the spec in the first place. > So for the moment it could be said that it's better to use the deprecated > window.orientation instead? Huh? I had no idea that was a thing? > At least this one seems to be currently the same in all browsers... Maybe, yeah… maybe we can deprecate angle and standardize that instead? What’s the use case you had in mind for angle?

> What’s the use case you had in mind for angle? For gyroscope-based controls (for VR, pano-viewing, games) it is necessary to know the device/screen orientation. The introducing of the ScreenOrientation API in iOS 16.4 therefore caused a problem with inverted screens - e.g. like here: https://krpano.com/forum/wbb/index.php?page=Thread&threadID=19282 In krpano I was using the ScreenOrientation API first (used by Chrome and Firefox and Android) and the window.orientation as second/as fallback (used by Safari). A quick search on GitHub seems to indicate that many other tools are either only using window.orientation or using window.orientation first and screen.orientation.angle as fallback. And that's also what I probably will implement now.

(In reply to Klaus Reinfeld from comment #12) > > What’s the use case you had in mind for angle? > A quick search on GitHub seems to indicate that many other tools are either > only using window.orientation or using window.orientation first and > screen.orientation.angle as fallback. And that's also what I probably will > implement now. Ok, I finally remembered where window.orientation is specified: https://compat.spec.whatwg.org/#dfn-window-orientation-angle I'll note that it doesn't define what "natural orientation" means, so it could become unreliable in the future also. I had another look at the orientation spec, and it does indeed allow for either 90 or 270 (Cleary this is come up before at some point in the past and we couldn't get agreement). I guess the least painful thing would be to maybe flip everything to counter-clockwise in the spec and then update WebKit. However, you might then need to then follow up with the Gecko folks to fix their implementation.

Filed spec bug: https://github.com/w3c/screen-orientation/issues/247 Klaus Reinfeld, if you are on GitHub, you might want to follow along. Otherwise I can ping you once we have a consensus on a solution.

Great! Thanks! I'm following.

Followup bug to change the behavior to counter clockwise: https://bugs.webkit.org/show_bug.cgi?id=255388