Open Bug 1568570 Opened 4 years ago Updated 5 months ago

Permission prompt full-screen test intermittent failures on macOS debug


(Firefox :: Site Permissions, defect, P3)

67 Branch




(Reporter: pbz, Unassigned, NeedInfo)


(Blocks 1 open bug, Regression)


(Keywords: regression)


(1 file)

On OS X 10.14 debug, when calling document.body.requestFullscreen() in the test, the full-screen request is sometimes denied:

"Request for fullscreen was denied because requesting element is not in the currently focused tab."

However, the changeFullscreen function ensures that window and content document are focused before requesting full-screen.

Try log:

Priority: -- → P3
See Also: → 1568648
Component: Site Identity → Site Permissions
Depends on: 1638499
Severity: normal → S4

The failure is caused by Document::FullscreenElementReadyCheck().
"docshell" said it is not active from "docshell->GetIsActive()"

When I reproducing the error on Mac, the attribute is set false when receiving "sizemodechange" or "occlusionstatechange".
At that time, window.isFullyOccluded is also true. That's why we set the attribute to false.

As I mentioned in bug 1618386, I found that we can eliminate the failures on OSX by setting preference as other fullscreen mochitests.
["full-screen-api.transition-duration.enter", "0 0"],
["full-screen-api.transition-duration.leave", "0 0"],
With the preferences, FullscreenTransitionDuration.IsSuppressed() is true and we pass nullptr as the screen to SetWidgetFullscreen and FullscreenTransitionTask

Currently, I don't understand the relationship between SetWidgetFullscreen and window.isFullyOccluded.
I will keep investigating it.

Xidorn, do you have any idea why the preference will help?

Flags: needinfo?(xidorn+moz)

Setting the preferences to 0 0 disables the fullscreen transition, which transitions the screen to black and then back.

When you disables the transition, the timing of going fullscreen changes, which could lead to lots of difference.

I'm not very familiar with the test, so I don't really know much about what can be done here without digging into it. I suppose you need to tweak some timing or so to make the test more reliable.

Flags: needinfo?(xidorn+moz)

Let me know if you want me to dig into it. I can probably help on weekend.

(In reply to Xidorn Quan [:xidorn] UTC+10 from comment #4)

Let me know if you want me to dig into it. I can probably help on weekend.

At first, I think the root cause of this failure on OSX and fission-Linux maybe the same.
After investigation, I know they are different.
Since the test is disabled on OSX now, I will investigate the failure on fission-Linux first.
It would be great if you can help on the failure on OSX.

Flags: needinfo?(xidorn+moz)

The fix for bug 1691892 and the fixes for its predecessors unfortunately don't resolve this one.

The order of the log lines before the failure isn't stable across runs.

Has Regression Range: --- → yes
Blocks: 1795491
You need to log in before you can comment on or make changes to this bug.