Closed Bug 1744288 Opened 2 years ago Closed 1 year ago

Behavior for screenOrientation.lock demo is different from FF and Chrome

Categories

(GeckoView :: GeckoViewExample, enhancement, P3)

Unspecified
All
enhancement

Tracking

(firefox110 wontfix, firefox111 fixed)

RESOLVED FIXED
111 Branch
Tracking Status
firefox110 --- wontfix
firefox111 --- fixed

People

(Reporter: calu, Assigned: m_kato)

References

(Blocks 1 open bug)

Details

(Whiteboard: [geckoview:m97])

Attachments

(4 files, 1 obsolete file)

Investigate the difference of demo site https://usefulangle.com/demos/105/screen.html on Chrome vs Firefox. On GVE, a security warning is triggered when lockOrientation button is pressed. On the second press, the orientation will be locked to landscape.

Related web tests include onchange-event: https://searchfox.org/mozilla-central/source/testing/web-platform/tests/screen-orientation/onchange-event.html

Priority: -- → P1
Whiteboard: [geckoview:m97]
Assignee: nobody → calu

Using the demo page "usefulangle.com/demos/105/screen.html", there is a difference in Chrome vs FF behavior. On Chrome, pressing the "lock to landscape" immediately rotates and locks the screen. On Firefox, a security warning appears due to the screen not being fullscreen. The user then presses the lock screen button again to finally rotate the screen. We would like the behavior to be the same.

In GetLockOrientationPermission, a comment states that "Other content must be fullscreen in order to lock orientation". It then checks Fullscreen() by checking GetUnretargetedFullScreenElement(), which returns the top layer element with the status fullscreen. However, regardless, a Runnable nsCallRequestFullscreen task gets initated afterwards and applies fullscreen. I think maybe the comment is not true, that some content does not need to be fullscreen in order to lock orientation. I couldn't find the history on why this was written. Therefore, the solution would be to allow lock orientation permission.

An alternative is if we want to apply fullscreen when checking permission, but we'd need the request->element like in Document.cpp:15041 SetFullScreenElement(aRequest->Element()) to add the top layer and set it to fullscreen, which is done by the runnable request fullscreen task anyway.

Whiteboard: [geckoview:m97] → [geckoview:m97][geckoview:m98]
Attachment #9257174 - Attachment is obsolete: true
Severity: -- → S3
Priority: P1 → P3
Whiteboard: [geckoview:m97][geckoview:m98] → [geckoview:m97]

From https://w3c.github.io/screen-orientation/#dfn-pre-lock-conditions

a user agent might require a Document's top-level browsing context to be fullscreen

This is a different of interpretation for Gecko vs Blink.

  • Gecko need to wait for full screen request's completion to call screen lock
  • Blink doesn't wait for full screen request's completion to call screen lock. At least, it requires that fullscreen request is pending or completed

So, There is the following API call.

    let promise1 = document.documentElement.requestFullscreen();
    let promise2 = screen.orientation.lock('landscape-primary');

Blink

screen.orientation.lock doesn't throw any error even if promise1 isn't resolved. Then, promise1 is resolved then promise2 is resolved.

Gecko

screen.orientation.lock throw any error (security error) because requestFullscreen (promise1) isn't completed yet.

Assignee: calu → nobody

I have to re-check orientation lock on youtube.com when youtube.com might call orientation.lock since it won't check fullscreen is completed. (When I test it 1 month ago, they doesn't wait the completion of fullscreen.)

If previous test of orientationLockedExistingOrientation doesn't change to
landscape-primary, this test may be failure since screen orientation promise
may be resolved due to change of screen orientation by requestedOrientation.

So we should wait requestedOrientation is done before calling lockLandscape.

Assignee: nobody → m_kato
Status: NEW → ASSIGNED

This issue isn't spec issue. This is a kind of web compatibility issue.

UA can require per-lock conditions to use screen orientation lock [*1]. Gecko
and Blink require full screen to allow screen orientation lock.

But, actually, both is different.

  • Gecko requires fullscreen request is completed.
  • Blink requires fullscreen request is pending or fullscreen is completed.

It means that the following script is worked on Blink, but Gecko doesn't

element.requestFullscreen(); // <- Don't wait for completion
window.screen.orientation.lock("portrait");

YouTube etc don't wait for completion of fullscreen request to call
screen.orientation.lock() like this script. So I would like to change the
behavior like Blink for web compatibility.

Also, screen.orientation.lock() will return rejected promise if pending
fullscreen request is canceled.

*1 https://w3c.github.io/screen-orientation/#locking-the-screen-orientation

Depends on D149035

In https://github.com/webcompat/web-bugs/issues/99745 a site is experiencing the same issue (reproducible when setting dom.screenorientation.allow-lock to true).

When element.requestFullscreen is called, we dispatch small task via
Document::AsyncRequestFullscreen. But it doesn't append FullscreenRequests
to PendingFullscreenChangeList immediately. So if we want to check
whether we have pending full screen request, we have to run an event loop.

Although I would like to check whether we have pending full screen request for
screen.orientation.lock compatibility, since we don't append it to pending
list immediately, we don't have the easy way to detect it.

RequestFullscreen doesn't wait for the completion if it runs on content
process since RequestFullscreenInContentProcess doesn't wait for the result
of chrome event. If runs on chrome process, RequestFullscreenInParentProcess
is synchronous. But if we use a task to call SetFullscreenInternal` in it,
we can change to async.

Then, this change will append FullscreenRequests to pending list immediately,
so we can check it without event loop.

Depends on D149035

Attachment #9306208 - Attachment description: Bug 1744288 - Store pending full screen request when calling element.requestFullscreen immediately. r=smaug → Bug 1744288 - Store pending full screen request when calling element.requestFullscreen immediately. r=edgar
Pushed by m_kato@ga2.so-net.ne.jp:
https://hg.mozilla.org/integration/autoland/rev/83fb9c029597
Fix a timing issue of orientationLockedExistingOrientation. r=geckoview-reviewers,agi
https://hg.mozilla.org/integration/autoland/rev/6b14fe576625
Remove unused mPendingFullscreenRequests variable. r=smaug
https://hg.mozilla.org/integration/autoland/rev/7b6ef0ecfa3e
Store pending full screen request when calling element.requestFullscreen immediately. r=edgar
https://hg.mozilla.org/integration/autoland/rev/79d02690f754
Allow screen.orientation.lock even if fullscreen request is pending. r=smaug
Duplicate of this bug: 1810199
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: