Bug 254863 – iOS 16.4 - Screen Orientation API Inconstancy

• Status: RESOLVED
• Resolution: INVALID
• Component: Layout and Rendering

[Klaus Reinfeld]

Created attachment 465725 [details]
Screenshot comparison iPhone and Android devices

The ScreenOrientation.type and ScreenOrientation.angle values are different to the window.orientation value and also different to the values that Android devices are reporting in landscape mode (tested with iPhone and iPad).

Here a test-case and screenshots:
https://krpano.com/ios/bugs/ios164-screen-orientation/


This also affects multiple (non-updated) krpano-based virtual tours all around the world when using the gyroscope-control or using the VR-mode.
krpano used a Feature-check before using the Screen Orientation API, but didn't expect that iOS might introduced the API with a different behavior...

[Radar WebKit Bug Importer]

<rdar://problem/107512442>

[Marcos Caceres]

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?

[Karl Dubost]

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

[Marcos Caceres]

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

[Klaus Reinfeld]

@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.

[Karl Dubost]

Created attachment 465768 [details]
Firefox-nightly-113-pixel-7

This is the result with a pixel 7

[Marcos Caceres]

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.

[Marcos Caceres]

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

[Marcos Caceres]

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).

[Klaus Reinfeld]

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...

[Marcos Caceres]

(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?

[Klaus Reinfeld]

> 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.

[Marcos Caceres]

(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.

[Marcos Caceres]

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.

[Klaus Reinfeld]

Great! Thanks! 
I'm following.

[Marcos Caceres]

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