1567805 - Could screen orientation.unlock() return a promise?

Status: NEW

(Core :: DOM: Core & HTML, enhancement)

Description

[Marcos Caceres [:marcosc]]

This a discussion with Nicholas Alexander, Eugen Sawin and I had about potentially allowing .unlock() to return a promise. In an email discussion, Nicholas wrote:

So, there are a few things going on here. First, dating back to the Fennec/very early GV days, there was an ability to set a delegate to handle these types of messages. I believe nobody actually uses that functionality, so don't worry too much about that indirection.

The calls are invoked from the native layer here: https://searchfox.org/mozilla-central/source/mobile/android/geckoview/src/main/java/org/mozilla/gecko/GeckoAppShell.java#1703
Which is really just https://searchfox.org/mozilla-central/source/hal/android/AndroidHal.cpp#149.

Reading a bit more, I already see a Promise in play at https://searchfox.org/mozilla-central/source/dom/base/ScreenOrientation.cpp#177, but you resolve it immediately at https://searchfox.org/mozilla-central/source/dom/base/ScreenOrientation.cpp#178. You would like to resolve that promise only after unlocking completes? I.e., you're concerned that it might be that there's some asynchrony and Android or GeckoView takes some number of seconds to unlock?

Reading more deeply yet, I see that we actually just ignore this in GV: https://searchfox.org/mozilla-central/source/mobile/android/geckoview/src/main/java/org/mozilla/gecko/GeckoAppShell.java#551. But in Fennec, we eventually call through to https://developer.android.com/reference/android/app/Activity.html#setRequestedOrientation(int): see https://searchfox.org/mozilla-central/source/mobile/android/base/java/org/mozilla/gecko/GeckoApp.java#2592.

Now, the reason the code is structured in this way is that GV itself can't really manage this type of locking/unlocking/orientation stuff; that is the consuming App's responsibility. The existing delegate is trying to express that for Fennec and GV. But GV will need to grow some API for new consumers to use this (they won't want the existing delegate, I think). And new consumers will also need to call through to Android's setRequestedOrientation... and that is asynchronous. I can imagine a scheme where we set a flag saying "I'm waiting for an orientation change", and then when the Android Activity (in the consumer!) get's recreated we clear the flag (and resolve the promise), but that's tricky.

Comment 1

[Marcos Caceres [:marcosc]]

Related spec bug https://github.com/w3c/screen-orientation/issues/104

Comment 2

[Marcos Caceres [:marcosc]]

Attachment: Make orientation.unlock() return a promise

instead of dropping the promise internal promise on the floor, we can return it to content to make things less racy ... specially because you often need to .exitFullScreen() at the same time. At least, we will guarantee that the unlock task finishes before .exitFullScreen() is called.

Comment 3

[Marcos Caceres [:marcosc]]

Try:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=2c9f94022729870675f306a649f971a90b9cac6c

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Comment 6

[Kagami Rosylight [:saschanaz] (they/them)]

(The spec proposal is inactive and nobody ships it either)