1257029 - Allow fullscreen to be triggered by an orientation change event

Status: NEW

(Core :: DOM: Core & HTML, defect, P3)

Description

[Xidorn Quan [:xidorn] UTC+11]

Chrome guys proposed that fullscreen should be allowed inside an orientation change event (see URL). The plan is not to make orientation change a user gesture (like click/keypress), but is to add an exception that fullscreen request can be called inside orientation change event.

Comment 1

[Xidorn Quan [:xidorn] UTC+11]

I think this is fine, as far as orientation change is only on mobile, and mobile doesn't require fullscreen permission since long ago, and doesn't have the big concern around phishing.

But I still want to hear from the security team first. dveditz, do you have any concern here?

Comment 2

[Daniel Veditz [:dveditz]]

I don't see any problem with this.

(fwiw desktop doesn't have the permission request anymore either.)

Comment 3

[Andrew Overholt [:overholt]]

I'm marking this as backlog but feel free to change the notation here if you're going to work on it sooner or if it's urgent, Xidorn. Thanks.

Comment 4

[Jet Villegas (inactive)]

Joe: this is the fullscreen orientation bug for your team's backlog triage. Thanks!

Comment 5

[Joe Cheng [:jcheng] (please needinfo)]

thanks Jet
set the fennec triage flag to ?
I do see some android apps implemented this feature, which is quite nice.

Comment 6

[Rachelle Yang [:ryang][[e-mail]]]

We remove the tracking -fennec=?flag here, because it's a feature request.
and we are tracking this big in the meta Bug 1341545 - [meta] Fennec Feature backlog collection
Thank you!

Comment 7

[Xidorn Quan [:xidorn] UTC+11]

Looked into this a bit, it seems this is a bit non-trivial.

Basically, it doesn't seem to me that we can easily distinguish between a user-initiated and a script-initiated screen orientation change. A user-initiated change would be triggered by GeckoView.onConfigurationChanged which calls into GeckoScreenOrientation.update. The screen orientation lock API, when invoked, triggers the update method via GeckoScreenOrientation.lock, so we can say anything from GeckoScreenOrientation.lock is not user-initiated.

However, when the screen is actually changed by lock, GeckoView.onConfigurationChanged would also be invoked by the system, which would be ignored in C++ code due to nothing gets changed, though, so not a big deal. (Although it isn't totally clear to me whether this would be safe enough either.)

What makes it really a problem is that, for unlock, either from screen.orientation.unlock or from exiting fullscreen, the approach above doesn't work. Although GeckoScreenOrientation.unlock also invokes GeckoScreenOrientation.update, it doesn't know the target orientation, and when GeckoScreenOrientation.update is invoked, the screen orientation may or may not have been updated. If that hasn't been updated, then nothing would be propagated to Gecko side, and we would only get the one comes later from GeckoView.onConfigurationChanged.

If we incorrectly accept fullscreen request from such orientation change above, a page may be able to trap user from exiting fullscreen, which would be quite unfortunate.

I currently run out of idea how can we overcome this.