Closed Bug 1550759 Opened 6 years ago Closed 6 years ago

White bar at top of screen when selecting full screen on Youtube

Categories

(Core :: Layout, defect, P2)

Product:
Core
Component:
Layout
Version:
66 Branch
Platform:
Desktop
All
Type:
defect

Tracking

()

Status:
RESOLVED INCOMPLETE
Tracking Flags:
Tracking Status
firefox66 --- affected
firefox67 --- affected
firefox68 --- affected

People

(Reporter: colin.templeman, Unassigned)

References

Details

Attachments

(5 files)

firefox_white-bar_youtube.jpg
88.96 KB, image/jpeg
Details
Chromium_73.0.3683.103_no_white-bar_youtube.jpg
112.14 KB, image/jpeg
Details
web_3.32.0_no_white-bar_youtube.jpg
100.10 KB, image/jpeg
Details
Screencast of emilio reproducing the bug?
7.94 MB, video/webm
Details
Screencast of White Bar Bug
9.08 MB, video/mp4
Details

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:66.0) Gecko/20100101 Firefox/66.0

Steps to reproduce:

A clean install of Firefox and a fresh profile. Go to youtube, select a video and play. Wait a few seconds and click icon to go full screen (or hit 'f' on keyboard). Full screen is achieved. Hit 'f' or escape to restore then 'f' or click full screen again.

This is reproducible with the current repo version 66.0.4, the current stable 66.0.5 and the latest beta 67.0b18. This issue did not manifest on 66.0.3 and previous.

All other video sites tested are unaffected including Vimeo, TED, Metacafe, Twitch, Dailymotion

Actual results:

A white bar shows at the top of the screen when maximized (see screenshot). What makes this frustrating is that whilst mostly a white bar manifests, every so often a full screen is achieved again but does not remain. Clearly this makes it tricky to establish the underlying cause of the fault to reproduce with any reliability.

Expected results:

Youtube should be maximised and restored every time with no white bar.

With other Video sites seemingly unaffected, there was a possibility that it could just be a Youtube issue. But no other browsers exhibit this behaviour.

Whilst I feel this is unrelated, for completeness I did experience a previous issue when viewing HTML5 video content full screen which was tracked here https://bugzilla.mozilla.org/show_bug.cgi?id=1466864 which after triage was attributed to a bug in Xfwm4 which was fixed last July https://bugzilla.xfce.org/show_bug.cgi?id=14511.

OS: Xubuntu 19.04
Distributor ID: Ubuntu
Description: Ubuntu 19.04
Release: 19.04
Codename: disco

Also confirmed in the following versions:

Name Firefox
Version 66.0.4
Build ID 20190506095117
User Agent Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:66.0) Gecko/20100101 Firefox/66.0
OS Linux 5.0.0-14-generic

=======================

Name Firefox
Version 66.0.5
Build ID 20190507012018
Update History
Update Channel release
User Agent Mozilla/5.0 (X11; Linux x86_64; rv:66.0) Gecko/20100101 Firefox/66.0
OS Linux 5.0.0-14-generic

=======================

Name Firefox
Version 67.0b18
Build ID 20190506235559
Update History
Update Channel beta
User Agent Mozilla/5.0 (X11; Linux x86_64; rv:67.0) Gecko/20100101 Firefox/67.0
OS Linux 5.0.0-14-generic

Fine on Chromium

Also fine on Web (Powered by WebKitGTK+ 2.24.1)

I was reading Ars Technica just now and I watched the first embedded video on this page

I then clicked on the "Youtube" link to watch it on the Youtube website itself. The embedded video on Ars behaves perfectly (maximise & restore), on Youtube the issue reported is exhibited.

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0
20190507012018

I've seen it sporadically, but I have no idea if it's a browser problem. It seems to stem from #page-manager having margin-top: 56px which is presumably used to reserve space either for the main top bar or the privacy reminder bar.

:miketaylr do you know who might diagnose this and determine if it's a site issue?

Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(miket)
OS: Unspecified → All
Hardware: Unspecified → Desktop

I can only add that I've never encountered this issue myself until the 66.0.4 update. It's further coloured by the repeated "f" press actually bringing the desired result at some random point. It smacks of a timing issue of some sorts.

I can confirm this happened after the latest Firefox update on Linux Mint.

I can confirm this on FF 66.0.4 on Ubuntu 18.04. Tested with -safe-mode.

After I clicked 'remind me later' on the privacy reminder, the video was still moved downwards out of frame, but LESS so; ie the white bar got smaller.

Reproducible on Windows 10 x64 and Mac OS X 10.14 on Firefox Nightly 68.0a1, Firefox 67.0b19 and on Firefox 66.0.5.

status-firefox66: --- → affected
status-firefox67: --- → affected
status-firefox68: --- → affected
Component: Untriaged → Graphics
Product: Firefox → Core

Xidorn, I'm told you know your way around the full screen implementation. Does the issue description ring a bell? Any recommandation of people who could look at this bug?

Flags: needinfo?(xidorn+moz)

(clearing ni?, since this moved to gfx, but let me know if we need to investigate more)

Flags: needinfo?(miket)

(In reply to Gingerbread Man from comment #5)

It seems to stem from #page-manager having margin-top: 56px

(In reply to Mike Taylor [:miketaylr] from comment #14)

(clearing ni?, since this moved to gfx

It doesn't belong in Core :: Graphics. It's either a JavaScript or CSS issue. It would be useful if someone could determine if it's the site's fault or the browser's fault, hence the needinfo request.

I did a brief test on my macOS 10.14.4 with Firefox 66.0.5 and 68.0a1 (2019-05-15), and couldn't reproduce this issue any time.

Hani, in comment 12 indicated that this was reproducible among all platforms, could you explain your steps to reproduce on macOS and how frequent do you see it?

Xidorn, I'm told you know your way around the full screen implementation. Does the issue description ring a bell? Any recommandation of people who could look at this bug?

So I noticed that Youtube doesn't really fullscreen the video, instead it still has other components around, especially the top bar, which could potentially be the source of problem here.

If this happens only on Linux, there is a possibility that Youtube is running some code on the fullscreenchange event to record the viewport size, and calculate layout based on that. It can be problematic on Linux because Linux is the only platform where we don't have atomic fullscreen change (i.e. when fullscreen event is dispatched, the viewport may not have been sized properly) because GTK cannot give us any reliable signal for that. See bug 1254448.

If it happens on other platforms as well, then it's probably not that issue, and I don't have further idea what may be happening without being able to reproduce it locally.

Flags: needinfo?(xidorn+moz) → needinfo?(hani.yacoub)

I managed to reproduce it on Windows 10 x64, Ubuntu 18.04 and on MacOS 10.14 on the latest Firefox Nightly 68.0a1 (2019-05-16) with a fresh profile. But I observed that especially on MacOS it maybe intermittent and once the full screen mode is displayed correctly the issue may not accrue again, and you should try again with a fresh profile.

Steps to reproduce:

  1. Open Firefox Nightly with a fresh profile.
  2. Go to youtube.com, select any video and click on play.
  3. Press "f" or click on the on "Full screen" icon after the video is played.
  4. Press "f" or click on the on "Full screen" icon again to exit the full screen.
  5. Press "f" or click on the on "Full screen" icon once again.
Flags: needinfo?(hani.yacoub)

As I state in comment 7 above, I have already discovered that if you hit the "f" key enough times it will go full-screen as it normally should. But this behaviour is random and unreliable.

(In reply to Colin Templeman from comment #18)

As I state in comment 7 above

Sorry that may be comment 6 although I swore it was 7 ....

It doesn't belong in Core :: Graphics. It's either a JavaScript or CSS issue.

Tentatively moving to CSS.

Component: Graphics → CSS Parsing and Computation
Priority: -- → P3

Actually... Let's call this layout for now (it's pretty unlikely it's a CSS engine bug per se).

I couldn't reproduce it myself, fwiw.

But without someone digging into what youtube is doing this is pretty hard. Mike, is that something you or someone on your team may be able to help with?

Component: CSS Parsing and Computation → Layout
Flags: needinfo?(miket)
Priority: P3 → --

This doesn't repro for me in a new 66.0.5 profile on Ubuntu 18. Tom, can you check if it reproduces for you?

(I do see the top white menu/navbar transition up and away on fullscreen... perhaps it can somehow fail?)

Flags: needinfo?(miket) → needinfo?(twisniewski)

Yes and no. I can sometimes see a white bar under the video if I hit 'f' after scrolling down the page so the video is entirely off-screen. It looks like the video is just shifted off the top of the screen when this happens, cutting off some content.

But the odd thing is that if I try to inspect the white space, the inspector doesn't seem to think anything is there. It also looks like the <ytd-app> element logically should take up the whole view (position:absolute, top:0, bottom:0), yet it does not. After scrolling, there is a new bit of CSS applying to it which changes its position to relative:

ytd-app[scrolling_] {
    position: relative;
    top: 0;
    left: 0;
    right: calc((var(--ytd-app-fullerscreen-scrollbar-width) + 1px) * -1);
    bottom: 0;
    overflow-x: auto;
}

And when I manually override the position back to absolute, the problem goes away.

But I can't see any obvious reason for its relative position to be shifted upward. So far I just know that deleting the <head> tag also makes the problem go away, so this would seem to be related to their CSS. I'll keep investigating.

Flags: needinfo?(twisniewski)

Ah, disabling/removing this rule in their <style name="global_styles"> element makes the problem go away:

body.no-scroll {
 overflow:hidden
}

But the body element always seems to have this CSS applied to it, and have the same zero height, whether the problem shows up or not.

And I have no idea why the content would be clipped or relatively shifted just because of this rule, as there are no other clear clues I'm seeing in the CSS or layout inspectors.

Mike, who do you feel might have some insight into why fullscreen mode can affect this?

Flags: needinfo?(miket)

Emilio, how much do you know about fullscreen? ^_^

Flags: needinfo?(miket) → needinfo?(emilio)

Not that much actually, Xidorn would be a better guess :(

There are media-queries that are affected by the fullscreen state, fwiw. Not sure if that helps much.

(In reply to Thomas Wisniewski [:twisniewski] from comment #23)

And when I manually override the position back to absolute, the problem goes away.

If when you're on this state you go back to relative, do you see the issue again? If not then it's likely a layout bug...

Flags: needinfo?(emilio) → needinfo?(twisniewski)

Rather bizarrely, I just tested again and now the CSS for ytd-app[scrolling_] has position:absolute instead of relative, so I don't think that's related to the issue anymore.

However, the overflow:hidden rule that I mentioned above does still "cause" the bug, and when I toggle it off off and on, the bug does not reappear. Plus opening the devtools seems to cause the problem to go away as well, so I guess that implies a layout bug?

Flags: needinfo?(twisniewski) → needinfo?(emilio)

Yeah, I guess so... Now some sort of reduction would of course be amazing... I still haven't been able to reproduce a single time :-(

Flags: needinfo?(emilio)

(Not asking you to do that of course, but without that this is going to be pretty hard to fix...)

Yeah, I actually tried making a reduced case earlier, but it just wasn't happening. I'll try again when I can.

(In reply to Thomas Wisniewski [:twisniewski] from comment #23)

this would seem to be related to their CSS.

Any thoughts on comment 5? I worked around the issue with this in userContent.css:

@-moz-document domain("youtube.com") {
ytd-app[masthead-hidden_=""] #page-manager { margin-top: 0px !important; }
}

(In reply to Emilio Cobos Álvarez (:emilio) from comment #28)

Yeah, I guess so... Now some sort of reduction would of course be amazing... I still haven't been able to reproduce a single time :-(

Interestingly, I can't reproduce this on my PC either. Only on my notebook. Both run Ubuntu 18.04.

My daughter couldn't reproduce this issue on her notebook walking Windows 10 Home.

Jan

FYI Just checked: also reproducible on my dual-boot laptop running Xubuntu 18.04 (FF 66.0.5) and Windows 8.1 (FF 66.0.5)

Not sure if I can be of any help, but this is annoying enough for me to register and leave a +1..
I am seeing this on two machines (Win10x64 Home / Win10x64 Pro) via a linked FF Profile but also on new/portable instances.
Is there any additional info that could be supplied? To me this seems that the transition of the yt top bar isnt following through correctly and thus gets stuck somehow. The colour changes if you use yt dark mode and if you click in the scroll/search bar the complete top bar including search box etc becomes visible.

The best way to help is probably trying to find some test-case that I can reproduce so I can take a look on a debugger and see who's at fault.

I tried to reproduce quite a few times again today and no such luck... But I'm on Linux + Wayland so fullscreen may be way different than in Windows.

Aand as soon as I write, I manage to catch it on XWayland (classic).

Thomas, what I see does not go away when I open devtools and such. Can you record an screencast of what you see by any chance?

What I see seems more like what Gingerbread Man is seeing. The spacing comes from the margin-top in this rule:

#page-manager.ytd-app {
    --ytd-toolbar-offset: var(--ytd-masthead-height, 56px);
    overflow-x: auto;
    margin-top: var(--ytd-masthead-height, 56px);
    display: flex;
    -ms-flex: 1 1 0.000000001px;
    -webkit-flex: 1;
    flex: 1;
        flex-basis: 0%;
    -webkit-flex-basis: 0.000000001px;
    flex-basis: 0.000000001px;

}

Where --ytd-masthead-height:112px, set on <ytd-app>'s style attribute.

Flags: needinfo?(twisniewski)

(And it does not go away when I re-enter fullscreen, fwiw)

Is that what everybody is seeing? Or are we chasing two different bugs?

(That was on a clean nightly spawned with mozregression --launch 2019-05-19 -a https://www.youtube.com/watch\?v\=SQNtGoM3FVU)

Also, I can confirm that on Chromium I see the same if I set the --ytd-masthead-height:112px;. It's just that on Chrome it's properly set to zero ;)

Sent the mozilla-youtube-discuss@ mailing-list an email:

Hi YouTube folks,

Over in https://bugzilla.mozilla.org/show_bug.cgi?id=1550759, we're seeing a
strange margin when entering fullscreen on Firefox, that is relatively easy
to reproduce on a clean profile, looks like.

See https://bugzilla.mozilla.org/show_bug.cgi?id=1550759#c36 for my
poke-around, and comments around it for a screencast of the bug (as seen, you
may have to enter fullscreen twice).

Seems like on Firefox the --ytd-masthead-height custom property in the
style attribute of <ytd-app> ends up with a value of 112px, while on
Chromium it ends up being zero. This variable is used in a margin-top
declaration which causes the at the top spacing.

I saw two scripts updating the value of this property by poking at the
source. One of them was using getComputedStyleValue("height"), the other
one was setting it directly to zero. But the code was a bit unscrutable, thus
the email asking if somebody with access to the actual source and knowledge
of how YouTube works could take a look.

Do you know what kind of race / scheduling difference / browser bug could be
causing this? If it's a Firefox bug I'd love to know so I can fix it. If it
happens to be a YouTube bug I'd also be interested in knowing, mostly by
curiosity

Thanks in advance,

-- Emilio

This is what I see during this bug. Cropped out my Taskbar but you get the idea.

Yeah, so it's the same. It's a bit less high because I was on a clean profile and thus the privacy banner contributed to the space as well.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #36)

Thomas, what I see does not go away when I open devtools and such. Can you record an screencast of what you see by any chance?

Yes, please see : https://thomas.tanrei.ca/moz/Screencast%20of%20lower%20white%20bar%20bug.mov (Mojave's recorder made a larger file than Bugzilla would accept).

All I do there is scroll down with my MacBook's trackpad, press 'f', and see a white bar sometimes under the video, as shown. And yes, this is reproducing for me on my Macbook as well as a Linux desktop.

(In reply to Gingerbread Man from comment #31)

(In reply to Thomas Wisniewski [:twisniewski] from comment #23)
Any thoughts on comment 5? I worked around the issue with this in userContent.css:

@-moz-document domain("youtube.com") {
ytd-app[style*="fullerscreen"] #page-manager { margin-top: 0px !important; }
}

That doesn't help with the issue I'm seeing, so I suspect they're unrelated.

Flags: needinfo?(twisniewski)
Priority: -- → P2

(It sounds like that YouTube is probably rolling in some new UI change which may cause issues on Firefox... which may explain why it is reproduced only by some people but not others.)

I noticed something else today: 1. this also happens in MS Edge, which i was not aware of until today 2. I think i stumbled upon some workaround. I think this depends on all cookies etc cleared, so that the data regulations reminder is still there (which adblockers hide but not "accept"!). Now if I play the video, the colored bars happen, depending on normal mode, darkmode, etc. Go out of fullscreen, accept the banner thingy (or remind me later or whatever it is called), go back to fullscreen: the bars are still happening. BUT: Reload the page (edit: or select a new video, so a new site in fact) (while having accepted the banner thing before) and youtube works normal again. I have not been able to get the colored bars back at this point until i clear the cookies or close and reopen a private window. ..So this looks like that the user interaction with the banner does not get communicated to the site, but only after a reload..? Sorry that i cant phrase this any clearer.

I nagged youtube folks again, though haven't received any response yet since comment 41...

Dont know if this helps people or not but just wanted to contribute and hopefully it helps someone
It definitely looks like its a youtube problem because if anyone has ublock origin installed,putting this in their filters.....
youtube.com##.no-scroll #page-manager:style(margin-top: 0px !important)
solves the problem (at least for me anyhow)
I dont log in to youtube and just use the site without account and have been experiencing the white bar issue and this solved it for me
Thank you

In fact I use it the same way most of the time, so this is very welcome!
I have added this to origins my filters and tested some videos, normal mode, private mode etc and so far this seems to be working. Fullscreen works again as expected. Thank you for this, bugz, this was really annoying, at least now there is an automated workaround.

I just noticed this problem too (I do not regularly watch youtube videos with Firefox on my Windows 10 machine, but today I wanted to).

I debugged the youtube javascript a little and it seems to first set --ytd-masthead-height to zero in https://www.youtube.com/yts/jsbin/desktop_polymer_sel_auto_svg_home_v2-vfl-tch-I/desktop_polymer_sel_auto_svg_home_v2.js and later to the height of #masthead, 56px in my case (112px is probably before accepting the privacy policy).

I suspect either firefox layout being more lazy than it used to, or the youtube code takes another path due to feature detecting a recently added/removed feature.

However, while switching back and forth to record the stacktrace (single monitor computer) the problem just disappeared.

They replied, fwiw:

Hi Emilio,

sorry for the late reply, this is being tracked internally as b/133763782.

Okay so it's been a few months since I reported this bug and I've been using the Ublock stanza whilst awaiting a fix. However, I checked just now without the stanza and I was unable to reproduce this on Firefox 67.0.4 - Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:67.0) Gecko/20100101 Firefox/67.0

So can anyone else still reproduce the problem? If not, does anyone know where the fix was made?

A few days ago I removed the rule on one of my machines and have also not had this happen again. So maybe youtube did in fact fix it on their end..?

It would be good to definitively determine this before closing the bug.

Emilio, I note above you seem to have contact with the team at youtube. Perhaps you could liaise with them and confirm please?

Flags: needinfo?(emilio)

I sent this to the thread:

Hi,

This looks fixed according to the people that reported the Firefox bug, thank you! Could you confirm?

Out of curiosity, do you know what caused the issue? If there's a subtle interop issue I'd be curious to know. Or was it just some sort of race condition that happened more often in Firefox due to task scheduling differences?

Cheers,

-- Emilio

Flags: needinfo?(emilio)

As reported above in comment 56, the reported problem is no longer an issue for me. Something has clearly been fixed somewhere.

I'm loathe to close this or any fault report without some formally stated resolution but with no further comment, this is at risk of becoming a "zombie" in the system. So unless anyone is still experiencing this issue or has anything else to add, I'll schedule a closure reminder for 14 days. Any objections?

I confirm that I have been affected by this issue as well, but do not experience it any more.

Yeah, I got no reply from Youtube, so nothing actionable.

Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: