1619370 - YouTube video player controls are not rendered in full screen mode of embedded iframe with Fission and page zoom

Status: RESOLVED FIXED

(Core :: Web Painting, defect, P3)

Description

[Chris Peterson [:cpeterson]]

See the new STR in comment 16.

---

Old steps to reproduce

1. In a Fission window, load https://www.w3schools.com/html/tryit.asp?filename=tryhtml_youtubeiframe
2. Try to play the embedded YouTube video by clicking the small Play button in the lower-left corner of the video (not the big red Play button in the center of the video).

Expected results

The small Play button is visible and can be clicked to play the video.

Actual results

The small Play button is not visible (nor any of the other bottom player controls), but you can still click where the buttons should be to activate them.

This is not a regression. I can reproduce this bug at least as far back as 71 Nightly.

Comment 1

[Chris Peterson [:cpeterson]]

This bug is probably related to, or a dupe of, Twitch video bug 1607375.

Comment 2

[Chris Peterson [:cpeterson]]

New steps to reproduce

1. In a Fission window, load https://wpsmackdown.com/embed-youtube-video-wordpress/
2. Scroll down to "01 Easiest Way to Embed a YouTube Video in WordPress" and play the embedded YouTube video.
3. Click the YouTube player's "full screen" button.

Actual result

The video goes full screen, but the video player controls are not visible in full screen.

I then press Ctrl+W to close the tab while it was full screen. Now my Firefox window is stuck in full screen and I can't see the window's tab bar.

Expected result

Chrome and a non-Fission Firefox window, YouTube's video player controls are visible in full screen.

Comment 3

[Chris Peterson [:cpeterson]]

The video player controls are visible in full screen for first-party YouTube.com videos.

Comment 4

[Chris Peterson [:cpeterson]]

WFM I can no longer reproduce this bug with the video player controls.

Comment 5

[Chris Peterson [:cpeterson]]

While verifying this bug, I found a different full screen YouTube problem and filed bug 1620341.

Comment 6

[Chris Peterson [:cpeterson]]

I'm reopening this bug because I can reproduce it again.

When I open https://wpsmackdown.com/embed-youtube-video-wordpress/, the embedded YouTube player will intermittently tell me that full screen is not permitted. In that case, try reloading the page. I don't know if that is a race condition in Firefox or YouTube code.

Comment 7

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

The priority flag is not set for this bug.
:overholt, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 8

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

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Comment 9

[Andrew Overholt [:overholt]]

Maybe this is a better component?

Comment 10

[Chris Peterson [:cpeterson]]

Moving to Graphics component. Nika suspects this is a graphics bug related to painting the controls or possibly a layout bug where we are not sending resize events correctly.

Tracking for Fission Nightly (M6) because this bug only affects some YouTube embeds.

Comment 11

[Miko Mynttinen]

Could not reproduce on Mac with the latest Nightly (WebRender enabled).

Comment 12

[Chris Peterson [:cpeterson]]

I can still reproduce this bug (but no longer 100% of the time) with the latest Nightly on Windows and macOS. Disabling Fission fixes the problem, but I can still reproduce when loading the video in a non-Fission window of a Fission session. I can't reproduce in a clean profile, even with Fission enabled. I could still reproduce with my normal profile in Safe Mode and all extensions disabled (but Fission still enabled). I tried resetting some non-default prefs I had set (such as network.http.http3.enabled=true), but I could still reproduce the bug sometimes but not 100% of the time. It feels like I am able to reproduce the problem more easily if I load the video and go full screen very soon after launching Firefox.

Comment 13

[Jessie [:jbonisteel] pls NI]

Chris, just to confirm - do you still see this issue? Do you have WebRender enabled as well? And getting clear on what STR produce this most consistently would be helpful

Comment 14

[Chris Peterson [:cpeterson]]

(In reply to Jessie [:jbonisteel] pls NI from comment #13)

Chris, just to confirm - do you still see this issue? Do you have WebRender enabled as well? And getting clear on what STR produce this most consistently would be helpful

I can still reproduce this bug in 78 Nightly, but I don't think it's a WebRender bug:

• I can reproduce the bug in my daily driver Fission profile, with or without WebRender.
• I can't reproduce in a clean Fission profile, with or without WebRender.

Does that mean this is not a graphics bugs? Is there any graphics code that is common to both WebRender and non-WebRender?

I'm not sure yet what's different between my daily driver and clean profiles. I can reproduce the bug in my daily driver Fission profile in Safe Mode (Fission without extensions or WebRender). I will keep looking.

Comment 15

[Jessie [:jbonisteel] pls NI]

Hm, that is odd. I am not quite sure what it means. I am going to see in QA can reproduce, so we can get more info.

Since it seems to be inconsistent, I don't think it needs to block M6 but we can change that if we learn more about this and it does seem more important.

Andrei, can we see if QA can repro this? Thanks.

Comment 16

[Chris Peterson [:cpeterson]]

Good news: I have STR!

When fission.autostart = true, you can reproduce this bug by zooming the page (before or after fullscreening the video) with Ctrl+= (even in a non-Fission window!). I wasn't able to reproduce the problem in a clean profile because my daily profile's "Default zoom" setting (in about:preferences#general) is non-default value 110%.

Moving this bug to the Layout component because page zoom is the layout team's responsibility.

Since we have STR, I will clear the needinfo to QA and move this bug from Fission M7 Beta milestone to Fission Nightly M6c.

Comment 17

[Rachel Tublitz [:rachel]]

S1 or S2 bugs need an assignee - could you find someone for this bug?

Comment 18

[Hiroyuki Ikezoe (:hiro)]

I think I am not able to reproduce the issue on my Linux box. In the fullscreen state the controls are zoomed in/out properly in response to zoom value changes.

Chris, are you still able to reproduce this issue on your side?

Comment 19

[Chris Peterson [:cpeterson]]

(In reply to Hiroyuki Ikezoe (:hiro) from comment #18)

I think I am not able to reproduce the issue on my Linux box. In the fullscreen state the controls are zoomed in/out properly in response to zoom value changes.

Chris, are you still able to reproduce this issue on your side?

Yes. I can reproduce this bug on Windows 10 in a clean user profile with Nighty 79 build 2020-06-10. But I can no longer reproduce this bug in my regular user profile with Fission. Surprising, this is the reverse of the behavior I saw in comment 14:

(In reply to Chris Peterson [:cpeterson] from comment #14)

• I can reproduce the bug in my daily driver Fission profile, with or without WebRender.
• I can't reproduce in a clean Fission profile, with or without WebRender.

I don't know what changed. When I try to bisect the apparent fix using mozregression with my regular user profile, I can reproduce the problem again. So running Nightly using the same user profile produces different results when run from the Windows Command Prompt (can't repro bug) or from mozregression (can repro bug).

My Windows' default scaling setting ("Make everything bigger" in Windows' Ease of Access settings) is the default "250% (Recommended)", if that matters.

Comment 20

[Sean Voisen (:svoisen)]

(In reply to Rachel Tublitz [:rachel] from comment #17)

S1 or S2 bugs need an assignee - could you find someone for this bug?

I'm not going to assign this yet until we begin on Fission M6c work in earnest (which is soon). I still think it's S2, but only with Fission enabled of course.

Comment 21

[Hiroyuki Ikezoe (:hiro)]

I could reproduce the issue locally on my linux box so I am going to investigate to see whether this is an issue in layout or in gfx tomorrow. Interestingly even though the controls are not visible at all, hit testings work as expected as if there are controls, so I suppose it's a gfx issue.

Comment 22

[Hiroyuki Ikezoe (:hiro)]

Gosh! I can't reproduce it this morning....

Comment 23

[Hiroyuki Ikezoe (:hiro)]

As of now I believe either bug 1646491 or bug 1597439 should fix this.

Comment 24

[Hiroyuki Ikezoe (:hiro)]

So for future references, what I did to reproduce the issue on Linux is;

1. Set layout.css.devPixelsPerPx to 1.6 (it's probably depending on environments)
2. Open https://wpsmackdown.com/embed-youtube-video-wordpress/
3. Zoom the document in 133%
4. Play the embeded youtube video there
5. Make it fullscreen

Comment 25

[Neha Kochar [:neha]]

Emilio, would you know what could be the cause here?

Comment 26

[Emilio Cobos Álvarez (:emilio)]

Not really off the top of my head, but it doesn't seem layout, seems more of a display-list building issue, because stuff is still correctly positioned according to devtools.

In fact, turning of retained display lists with layout.display-list.retain=false makes this bug completely unreproducible.

Hiro, Chris, can any of you confirm that the bug goes away with layout.display-list.retain=false?

My guess is that RDL is somehow using a visible / building rect based on the fission iframe clip, and is not accounting for the document being fullscreen. But it's just a guess at this point.

Comment 27

[Emilio Cobos Álvarez (:emilio)]

And if any of you can confirm the above, we should move this to "Web Painting" :)

Comment 28

[Chris Peterson [:cpeterson]]

Hiro, Chris, can any of you confirm that the bug goes away with layout.display-list.retain=false?

And if any of you can confirm the above, we should move this to "Web Painting" :)

Yep! The bug goes away with layout.display-list.retain=false, so I will move this bug to the "Web Painting" component.

Comment 29

[Neha Kochar [:neha]]

Matt, could you please find someone to fix this in Fx82?

Comment 30

[Matt Woodrow (:mattwoodrow)]

Miko, any chance you can look into this while I'm away?

Comment 31

[Neha Kochar [:neha]]

Matt, bringing this back in your queue for your attention, please. :)

Comment 32

[Miko Mynttinen]

Attachment: 1619370.html

Simplified testcase, same STR.

Comment 33

[Neha Kochar [:neha]]

Miko, please provide an ETA for the fix in the whiteboard field as M6b is nearing completion.

Comment 34

[Miko Mynttinen]

Attachment: 1619370.html

Comment 35

[Miko Mynttinen]

Attachment: fullscreen.html

Comment 36

[Miko Mynttinen]

I have managed to reduce the testcase further, this seems like a more generic fullscreen issue with retained display lists, rather than just Youtube specific bug.
The reason why the video controls disappear is because the visible rect calculation here1 ends up being empty. This is probably due to a missing zoom factor or offset somewhere in the display list building code.

Comment 37

[Miko Mynttinen]

Attachment: Bug 1619370 - Return the rect from BrowserChild::GetVisibleRect() in app units r=mattwoodrow

Comment 38

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7ed2e1d98e9c
Return the rect from BrowserChild::GetVisibleRect() in app units r=mattwoodrow

Comment 39

[Alexandru Michis [:malexandru]]

https://hg.mozilla.org/mozilla-central/rev/7ed2e1d98e9c

Comment 40

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

Since the status are different for nightly and release, what's the status for beta?
For more information, please visit auto_nag documentation.