Open Bug 1257029 Opened 9 years ago Updated 2 years ago

Allow fullscreen to be triggered by an orientation change event

Categories

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

defect

Tracking

()

Tracking Status
firefox48 --- affected

People

(Reporter: xidorn, Unassigned)

References

(Blocks 1 open bug, )

Details

(Keywords: dev-doc-needed, Whiteboard: btpp-backlog)

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.
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?
Flags: needinfo?(dveditz)
I don't see any problem with this. (fwiw desktop doesn't have the permission request anymore either.)
Flags: needinfo?(dveditz)
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.
Whiteboard: btpp-backlog
Blocks: 746437
No longer blocks: fullscreen-api
Flags: needinfo?(bugs)
Joe: this is the fullscreen orientation bug for your team's backlog triage. Thanks!
Flags: needinfo?(bugs) → needinfo?(jcheng)
thanks Jet set the fennec triage flag to ? I do see some android apps implemented this feature, which is quite nice.
tracking-fennec: --- → ?
Flags: needinfo?(jcheng)
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!
tracking-fennec: ? → ---
Priority: -- → P3
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.
Component: DOM → DOM: Core & HTML
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.