Should the -secondary orientations be exposed?

[smfr]

Are there any use cases for locking to the upside-down (portrait-secondary, landscape-secondary) orientations? Generally people would only care about landscape and portrait, and would want the device to choose the closest one to rotate to.

[smfr]

In addition, exposing portrait-secondary and landscape-secondary orientation types are an additional bit of fingerprinting data over screen height and width.

[marcoscaceres]

We did have use cases of this in games and apps... but I can't for the life of me remember what we did with the use cases :( I'm trying to recall if there was any valid use case for "*-secondary", but I'm also coming up empty.

@mounirlamouri can you think of anything? I might be worth revising.

[smfr]

Another problem with the secondary orientations is that the author probably doesn't have enough information about the device to know where the physical buttons, cameras etc are, and a specific orientation that works on one kind of device may be bad for another.

[mounirlamouri]

Can you detail what's the fingerprinting problem with exposing secondary types?

[smfr]

You can detect people who always hold their device upside-down (some people do this).

[mounirlamouri]

WebKit introduced window.orientation which already exposes that information. Unless browsers are planning to deprecate this property?

[marcoscaceres]

On MDN, at least, window.orientation is marked as deprecated.

@othermaciej might have some insights on the future of window.orientation in Safari on iOS?

Seems it's also supported on Samsung Internet... @torgo, is that something you would consider deprecating from Samsung Internet?

With regards to dropping "*-secondary" in Firefox, I think I'd be ok with that but I'd have to double check with our Android team if they can come up with any legit use cases.

[mounirlamouri]

window.orientation is deprecated but even if we could remove it (I would doubt it, it's used widely), screen.orientation.angle exposes the same information.

Secondary types are meant to lock the screen orientation, not to detect it. The read part is just better than the angle as it provides more semantic information but nothing that can't be guessed from just reading the angle.

[marcoscaceres]

window.orientation is deprecated but even if we could remove it (I would doubt it, it's used widely),

I think it’s WebKit’s call, right? Chrome and Firefox don’t ship it.

screen.orientation.angle exposes the same information.

True, but that one is also highly unreliable iirc from our testing. Different devices report the opposite of what one would expect.

[mounirlamouri]

window.orientation is deprecated but even if we could remove it (I would doubt it, it's used widely),

I think it’s WebKit’s call, right? Chrome and Firefox don’t ship it.

It's implemented in Blink and I think Mozilla implemented it too. Basically, it has a full browser support.

screen.orientation.angle exposes the same information.

True, but that one is also highly unreliable iirc from our testing. Different devices report the opposite of what one would expect.

Why would that be? We didn't get that kind of feedback for Chrome.

[marcoscaceres]

It's implemented in Blink and I think Mozilla implemented it too. Basically, it has a full browser support.

found it... MDN is wrong and you are right. Android only:

#if defined(MOZ_WIDGET_ANDROID)
// https://compat.spec.whatwg.org/#windoworientation-interface
partial interface Window {
  [NeedsCallerType]
  readonly attribute short orientation;
           attribute EventHandler onorientationchange;
};
#endif

Why would that be? We didn't get that kind of feedback for Chrome.

I think Johanna had found it to be unreliable - but I guess you would have had more people yelling about it.

[marcoscaceres]

Secondary types are meant to lock the screen orientation, not to detect it. The read part is just better than the angle as it provides more semantic information but nothing that can't be guessed from just reading the angle.

Ok, looks like it's here to stay - with the control that @mounirlamouri points to. As you can only set it, that mitigates the finger printing concern (even though it's potentially kinda useless in practice).