1912338 - Thin white bar across top of screen in full screen mode

Status: VERIFIED FIXED

(Core :: Audio/Video: Playback, defect, P3)

Description

[Doug Hockin]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:129.0) Gecko/20100101 Firefox/129.0

Steps to reproduce:

Visit any streaming website that offers full screen mode for viewing. Start video. Go into full screen mode. Have tried YouTube, Amazon, PBS and Criterion Channel. Happens on all four. Does not happen on Spotify App.

Actual results:

Video plays full screen but there is a thin white bar across the top of the screen.

Expected results:

No white bar across top of screen

Comment 1

[Doug Hockin]

MacOS 11.7.10 running on Macbook Pro Retina 13" late 2013

Comment 2

[Doug Hockin]

I've tried to do a full screen capture, but the white line is missing from the screen capture.

Comment 3

[Doug Hockin]

Attachment: IMG_0698 cropped.jpg

Cropped version of cellphone photo taken of laptop with white line showing at top. Full file was too large to upload.

Comment 4

[Doug Hockin]

Attachment: Screen Shot 2024-08-08 at 11.46.39 AM.png

A full screen capture. White line is very thin and hard to see at top, but definitely there.

Comment 5

[Doug Hockin]

Comment on attachment 9418405 [details]
IMG_0698 cropped.jpg

Cropped cellphone photo. Full sized photo too large to upload. White line visible at top.

Comment 6

[Doug Hockin]

Comment on attachment 9418406 [details]
Screen Shot 2024-08-08 at 11.46.39 AM.png

Probably need a viewer with a black background to see the white line at the top of this. It's not visible if the viewer background is white.

Comment 7

[Paul Adenot (:padenot)]

Brad, does this look familiar? How should we debug this?

Comment 8

[Brad Werth [:bradwerth]]

Thanks for filing! Looks like we have some kind of rounding error with our layer sizing, something like that. Or possibly the menubar isn't fully hidden. Would you please try these things:

1. Try some different resolutions. If the problem occurs with some resolutions but not others, please post the problematic resolutions to this Bug.
2. Turn on animated menubar for fullscreen. It will be somewhere in System Settings. In macOS 14, it's in Control Center. Not sure how it's listed in macOS 11. When you've set this setting, and when the white line is visible, try moving the mouse up to make the menubar appear, then away to make it disappear again. Does that change the behavior?

I might be able to think of some other things. I'll try to reproduce on a few different macOS setups.

Comment 9

[Doug Hockin]

1. Changing screen resolution, which I've never done before and Preferences calls "Scaled", doesn't make any difference in white line at top behaviour.

2. While full screen with white line at top visible, if I move my cursor to the top, the menu bar and window title bar appear. When I then move the cursor down those two disappear and the white line is gone.

If I click in the middle of the window to pause the video, the white line reappears and remains as I click to restart, click to pause,... a

With the white line not visible, clicking anywhere on the video control bar at the bottom will also cause the white line at top to appear.

Comment 10

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

The severity field is not set for this bug.
:jimm, could you have a look please?

For more information, please visit BugBot documentation.

Comment 11

[Brad Werth [:bradwerth]]

Attachment: macOS 10.15 titlebar white line.png

I haven't been able to reproduce this on my Intel Mac running macOS 10.15 (nor on any other Mac system). I do note that on macOS 10.15, there's a white line under the window title bar when it appears on a fullscreen window (image attached). Perhaps the white line you are seeing is this one, somehow still visible when the window titlebar slides out of view.

Let's see if we can find the change that caused this problem to occur on your system. Would you please run the tool mozregression which will do a binary search on Firefox builds to find the code that caused the problem for you?

In the meantime, I'll see if I can find out anything about why the titlebar is styled in that strange way, and if there's anything that we can do about it within Firefox.

Comment 12

[Doug Hockin]

I've just finished running mozregression. Does it automatically report somewhere that you will see or do I need to copy the output? Here's the end of the output:

2024-09-07T12:04:42.475000: INFO : Narrowed integration regression window from [7ec6274b, 90f4a437] (4 builds) to [7ec6274b, a623390b] (3 builds) (~1 steps left)
2024-09-07T12:04:42.477000: INFO : Running autoland build built on 2024-07-09 12:34:41.450000, revision 5cccb9c5
2024-09-07T12:05:26.579000: DEBUG : codesign verify exit code: 1
2024-09-07T12:05:26.580000: DEBUG : codesign verification failed for /private/var/folders/bq/s4jd_tmj34185h9twcmdpqw00000gn/T/tmpw5y9qfpd/Firefox Nightly.app, resigning...
2024-09-07T12:05:32.223000: INFO : Launching /private/var/folders/bq/s4jd_tmj34185h9twcmdpqw00000gn/T/tmpw5y9qfpd/Firefox Nightly.app/Contents/MacOS/firefox
2024-09-07T12:05:32.230000: INFO : Application command: /private/var/folders/bq/s4jd_tmj34185h9twcmdpqw00000gn/T/tmpw5y9qfpd/Firefox Nightly.app/Contents/MacOS/firefox -foreground -profile /var/folders/bq/s4jd_tmj34185h9twcmdpqw00000gn/T/tmpcuvv8wxe.mozrunner
2024-09-07T12:05:32.258000: INFO : application_buildid: 20240703203634
2024-09-07T12:05:32.258000: INFO : application_changeset: 5cccb9c5d12e12c0d9d78242fa92fda3e5681a67
2024-09-07T12:05:32.260000: INFO : application_display_name: Firefox Nightly
2024-09-07T12:05:32.269000: INFO : application_id: {ec8030f7-c20a-464f-9b0e-13a3a9e97384}
2024-09-07T12:05:32.269000: INFO : application_name: Firefox
2024-09-07T12:05:32.269000: INFO : application_remotingname: firefox-nightly-autoland
2024-09-07T12:05:32.269000: INFO : application_repository: https://hg.mozilla.org/integration/autoland
2024-09-07T12:05:32.270000: INFO : application_vendor: Mozilla
2024-09-07T12:05:32.270000: INFO : application_version: 129.0a1
2024-09-07T12:05:32.270000: INFO : platform_buildid: 20240703203634
2024-09-07T12:05:32.272000: INFO : platform_changeset: 5cccb9c5d12e12c0d9d78242fa92fda3e5681a67
2024-09-07T12:05:32.273000: INFO : platform_repository: https://hg.mozilla.org/integration/autoland
2024-09-07T12:05:32.274000: INFO : platform_version: 129.0a1
2024-09-07T12:06:53.933000: INFO : Narrowed integration regression window from [7ec6274b, a623390b] (3 builds) to [5cccb9c5, a623390b] (2 builds) (~1 steps left)
2024-09-07T12:06:53.965000: DEBUG : Starting merge handling...
2024-09-07T12:06:53.966000: DEBUG : Using url: https://hg.mozilla.org/integration/autoland/json-pushes?changeset=a623390b9ae5e52cc6111a730569a65522504330&full=1
2024-09-07T12:06:53.966000: DEBUG : redo: attempt 1/3
2024-09-07T12:06:53.967000: DEBUG : redo: retry: calling _default_get with args: ('https://hg.mozilla.org/integration/autoland/json-pushes?changeset=a623390b9ae5e52cc6111a730569a65522504330&full=1',), kwargs: {}, attempt #1
2024-09-07T12:06:53.974000: DEBUG : urllib3.connectionpool: Resetting dropped connection: hg.mozilla.org
2024-09-07T12:06:54.953000: DEBUG : urllib3.connectionpool: https://hg.mozilla.org:443 "GET /integration/autoland/json-pushes?changeset=a623390b9ae5e52cc6111a730569a65522504330&full=1 HTTP/1.1" 200 None
2024-09-07T12:06:55.008000: DEBUG : Found commit message:
Bug 1906034 - Show macOS titlebar if we are not drawing into it. r=mac-reviewers,spohl

Rather than always hiding the titlebar for ToolbarWindows, conditionally show it if we are not drawing into it.

Differential Revision: https://phabricator.services.mozilla.com/D215586

2024-09-07T12:06:55.008000: DEBUG : Did not find a branch, checking all integration branches
2024-09-07T12:06:55.016000: INFO : The bisection is done.
2024-09-07T12:06:55.019000: INFO : Stopped

Comment 13

[Brad Werth [:bradwerth]]

(In reply to Doug Hockin from comment #12)

I've just finished running mozregression. Does it automatically report somewhere that you will see or do I need to copy the output? Here's the end of the output:

2024-09-07T12:06:55.008000: DEBUG : Found commit message:
Bug 1906034 - Show macOS titlebar if we are not drawing into it. r=mac-reviewers,spohl

Rather than always hiding the titlebar for ToolbarWindows, conditionally show it if we are not drawing into it.

Differential Revision: https://phabricator.services.mozilla.com/D215586

Perfect, this is exactly what we hoped to find. This means that the code landing in Bug 1906034 caused this issue. Now we try to find a way to keep the fix for that Bug without causing this issue.

Sam, not sure if you have a setup that can replicate this problem, but please try to replicate it and find a fix if possible.

Comment 14

[Sam Johnson]

Interesting, I left the original fix for this issue in my patch to avoid this regression. I had some trouble reproducing, but I’ll try some more things to reproduce and fix.

Comment 15

[Sam Johnson]

I am able to reproduce using this configuration:

• 2018 MacBook Air
• macOS 11.7.2
• Firefox 130.0 (or the latest Nightly)
• Light mode selected in System Preferences
• Using the full-screen button in the player when viewing https://www.youtube.com/watch?v=obSH5F2DYvk

Comment 16

[Sam Johnson]

I can also reproduce on my Mac Studio running macOS 15.0 if I have the browser window titlebar enabled.

Comment 17

[Sam Johnson]

Attachment: Bug 1912338 - Consistently hide macOS titlebar separator for full screen windows. r?#mac-reviewers

In bug 1906034, I attempted to preserve the workaround for the white line issue from bug 1700211, but it did not prevent the white line from appearing. Hiding the separator in response to full-screen events avoids the issue.

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/bc9c2968fa17
Consistently hide macOS titlebar separator for full screen windows. r=mac-reviewers,bradwerth

Comment 19

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/bc9c2968fa17

Comment 20

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

Set release status flags based on info from the regressing bug 1906034

Comment 21

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

The patch landed in nightly and beta is affected.
:bradwerth, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox131 to wontfix.

For more information, please visit BugBot documentation.

Comment 22

[Sam Johnson]

Sigh, this fixed the issue on all OSes except macOS 11. I am investigating further.

Comment 23

[Brad Werth [:bradwerth]]

Sam has a greater understanding of this -- and is able to replicate the issue. I'll assign it to Sam. I will help land the patches and if Sam needs to assign it back to me for any reason, that's fine.

Comment 24

[Sam Johnson]

Documenting my findings for future archaeologists:

It appears that in macOS 11, MOZTitlebarAccessoryView's viewWillMoveToWindow: is called both when transitioning to full screen, and when transitioning out of full screen. In the case of transitioning into full screen, the window passed to viewWillMoveToWindow: has titlebarAppearsTransparent=false, meaning that the condition added to this function in bug 1906034 caused the title bar separator to always be enabled when in full screen on macOS 11. This indicates that the original assumption that this issue is related to titlebarAppearsTransparent is inaccurate. Unfortunately the original comment in this function misled me a bit here originally, but we will fix it :)

In later releases, viewWillMoveToWindow: seems to be called when transitioning out of from full screen, but not when transitioning to full screen. This is why disabling the title bar separator in windowDidEnterFullScreen: is also needed to fix the issue for later macOS releases (which was reproduce-able with the browser title bar enabled). Note that using windowDidEnterFullScreen: alone is not sufficient to solve the issue on macOS 11, which is why we have both.

Comment 25

[Sam Johnson]

Attachment: Bug 1912338 - Fix titlebar separator hiding workaround on macOS 11. r?#mac-reviewers

On macOS 11, MOZTitlebarAccessoryView's viewWillMoveToWindow: is called both when transitioning to full screen, and when transitioning out of full screen. In the case of transitioning into full screen, the window passed to viewWillMoveToWindow: has titlebarAppearsTransparent=false, meaning that the condition added to this function in bug 1906034 caused the title bar separator to always be enabled when in full screen on macOS 11. This patch fixes the logic to instead check if the passed NSWindow is our ToolbarWindow or something else.

On later macOS releases, MOZTitlebarAccessoryView's viewWillMoveToWindow: is called when transitioning out of from full screen, but not when transitioning to full screen. This is why disabling the title bar separator in windowDidEnterFullScreen: is also necessary.

Comment 26

[Markus Stange [:mstange]]

Thank you for the thorough investigation and sorry about the misleading comment!

Comment 27

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/123f918ba805
Fix titlebar separator hiding workaround on macOS 11. r=mac-reviewers,bradwerth

Comment 28

[Doug Hockin]

I also want to thank you for working so hard on this! Good going...

Comment 29

[Sam Johnson]

(In reply to Markus Stange [:mstange] from comment #26)

Thank you for the thorough investigation and sorry about the misleading comment!

No worries! I saw that your reduced testcase required titlebarAppearsTransparent=YES to reproduce the issue, so I'm thinking that some other property Firefox is setting (or change in a subsequent OS update) is causing us to hit the same buggy Apple code path even with titlebarAppearsTransparent=NO.

(In reply to Doug Hockin from comment #28)

I also want to thank you for working so hard on this! Good going...

Thank you for the detailed bug report! It helped me reproduce this issue which has been a bit elusive.

Comment 30

[pstanciu]

https://hg.mozilla.org/mozilla-central/rev/123f918ba805

Comment 31

[Sam Johnson]

:RyanVM, given the regression made it to ESR128 would you like me to request uplift of these patches? Also, would you like them uplifted to beta as well? The regression affected full screen video on macOS 11, as well as newer versions of macOS when the browser title bar is enabled.

Comment 32

[Ryan VanderMeulen [:RyanVM]]

Yes please.

Comment 33

[Sam Johnson]

Attachment: Bug 1912338 - Consistently hide macOS titlebar separator for full screen windows.

In bug 1906034, I attempted to preserve the workaround for the white line issue from bug 1700211, but it did not prevent the white line from appearing. Hiding the separator in response to full-screen events avoids the issue.

Original Revision: https://phabricator.services.mozilla.com/D221576

Comment 34

[Sam Johnson]

Attachment: Bug 1912338 - Consistently hide macOS titlebar separator for full screen windows.

In bug 1906034, I attempted to preserve the workaround for the white line issue from bug 1700211, but it did not prevent the white line from appearing. Hiding the separator in response to full-screen events avoids the issue.

Original Revision: https://phabricator.services.mozilla.com/D221576

Comment 35

[Sam Johnson]

Attachment: Bug 1912338 - Fix titlebar separator hiding workaround on macOS 11.

On macOS 11, MOZTitlebarAccessoryView's viewWillMoveToWindow: is called both when transitioning to full screen, and when transitioning out of full screen. In the case of transitioning into full screen, the window passed to viewWillMoveToWindow: has titlebarAppearsTransparent=false, meaning that the condition added to this function in bug 1906034 caused the title bar separator to always be enabled when in full screen on macOS 11. This patch fixes the logic to instead check if the passed NSWindow is our ToolbarWindow or something else.

On later macOS releases, MOZTitlebarAccessoryView's viewWillMoveToWindow: is called when transitioning out of from full screen, but not when transitioning to full screen. This is why disabling the title bar separator in windowDidEnterFullScreen: is also necessary.

Original Revision: https://phabricator.services.mozilla.com/D221909

Comment 36

[Phabricator Automation]

esr128 Uplift Approval Request

• User impact if declined: White line on screen with full screen video
• Code covered by automated testing: no
• Fix verified in Nightly: yes
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: On macOS, right-click the toolbar and choose Customize. Enable the title bar, then save. Then, visit any YouTube video and use the full-screen button within the player. There should not be a white line at the top of the screen.
• Risk associated with taking this patch: Low
• Explanation of risk level: Minor UI change
• String changes made/needed: None
• Is Android affected?: no

Comment 37

[Phabricator Automation]

esr128 Uplift Approval Request

• User impact if declined: White line on screen with full screen video
• Code covered by automated testing: no
• Fix verified in Nightly: yes
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: On macOS 11, right-click the toolbar and choose Customize. Enable the title bar, then save. Then, visit any YouTube video and use the full-screen button within the player. There should not be a white line at the top of the screen.
• Risk associated with taking this patch: Low
• Explanation of risk level: Minor UI change
• String changes made/needed: None
• Is Android affected?: no

Comment 38

[Phabricator Automation]

esr128 Uplift Approval Request

• User impact if declined: White line on screen with full screen video
• Code covered by automated testing: no
• Fix verified in Nightly: yes
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: On macOS 11, in light mode, right-click the toolbar and choose Customize. Enable the title bar, then save. Then, visit any YouTube video and use the full-screen button within the player. There should not be a white line at the top of the screen.
• Risk associated with taking this patch: Low
• Explanation of risk level: Minor UI change
• String changes made/needed: None
• Is Android affected?: no

Comment 39

[Phabricator Automation]

esr128 Uplift Approval Request

• User impact if declined: White line on screen with full screen video
• Code covered by automated testing: no
• Fix verified in Nightly: yes
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: On macOS 12 or higher, in light mode, right-click the toolbar and choose Customize. Enable the title bar, then save. Then, visit any YouTube video and use the full-screen button within the player. There should not be a white line at the top of the screen.
• Risk associated with taking this patch: Low
• Explanation of risk level: Minor UI change
• String changes made/needed: None
• Is Android affected?: no

Comment 40

[Sam Johnson]

Attachment: Bug 1912338 - Fix titlebar separator hiding workaround on macOS 11.

On macOS 11, MOZTitlebarAccessoryView's viewWillMoveToWindow: is called both when transitioning to full screen, and when transitioning out of full screen. In the case of transitioning into full screen, the window passed to viewWillMoveToWindow: has titlebarAppearsTransparent=false, meaning that the condition added to this function in bug 1906034 caused the title bar separator to always be enabled when in full screen on macOS 11. This patch fixes the logic to instead check if the passed NSWindow is our ToolbarWindow or something else.

On later macOS releases, MOZTitlebarAccessoryView's viewWillMoveToWindow: is called when transitioning out of from full screen, but not when transitioning to full screen. This is why disabling the title bar separator in windowDidEnterFullScreen: is also necessary.

Original Revision: https://phabricator.services.mozilla.com/D221909

Comment 41

[Phabricator Automation]

beta Uplift Approval Request

• User impact if declined: White line on screen with full screen video
• Code covered by automated testing: no
• Fix verified in Nightly: yes
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: On macOS 12 or higher, in light mode, right-click the toolbar and choose Customize. Enable the title bar, then save. Then, visit any YouTube video and use the full-screen button within the player. There should not be a white line at the top of the screen.
• Risk associated with taking this patch: Low
• Explanation of risk level: Minor UI change
• String changes made/needed: None
• Is Android affected?: no

Comment 42

[Phabricator Automation]

beta Uplift Approval Request

• User impact if declined: White line on screen with full screen video
• Code covered by automated testing: no
• Fix verified in Nightly: yes
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: On macOS 11, in light mode, right-click the toolbar and choose Customize. Enable the title bar, then save. Then, visit any YouTube video and use the full-screen button within the player. There should not be a white line at the top of the screen.
• Risk associated with taking this patch: Low
• Explanation of risk level: Minor UI change
• String changes made/needed: None
• Is Android affected?: no

Comment 43

[Phabricator Automation]

esr128 Uplift Approval Request

• User impact if declined: White line on screen with full screen video
• Code covered by automated testing: no
• Fix verified in Nightly: yes
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: On macOS 11, in light mode, visit any YouTube video and use the full-screen button within the player. There should not be a white line at the top of the screen.
• Risk associated with taking this patch: Low
• Explanation of risk level: Minor UI change
• String changes made/needed: None
• Is Android affected?: no

Comment 44

[Phabricator Automation]

beta Uplift Approval Request

• User impact if declined: White line on screen with full screen video
• Code covered by automated testing: no
• Fix verified in Nightly: yes
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: On macOS 11, in light mode, visit any YouTube video and use the full-screen button within the player. There should not be a white line at the top of the screen.
• Risk associated with taking this patch: Low
• Explanation of risk level: Minor UI change
• String changes made/needed: None
• Is Android affected?: no

Comment 45

[Dianna Smith [:diannaS]]

:sam can you rebase the beta patches? It had some failures landing

Comment 46

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/199f7c6e6f6f
https://hg.mozilla.org/releases/mozilla-beta/rev/69738794867d

Comment 47

[Ciprian Georgiu, Desktop QA]

I have reproduced this issue with an affected Nightly build (2024-08-08), on macOS 14 when the title bar is enabled.

The issue is verified as fixed on latest Nightly 132.0a1 and Beta 131.0b7 under macOS 14.

Comment 48

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr128/rev/a266d935ccdd
https://hg.mozilla.org/releases/mozilla-esr128/rev/e4d47fc4145e

Comment 49

[Giorgia Nichita, Release Desktop QA]

I have reproduced this issue with an affected Nightly build (2024-08-08), on macOS 13 ARM, with the title bar enabled.
The issue is verified as fixed on Firefox 128.3.0esr under macOS 13 ARM and macOS 14.

Comment 50

[Doug Hockin]

The issue is verified as fixed on Firefox 131.0 under macOS 11.7.10 running on a MacBook Pro (Retina, 13", Late 2013).
Thanks so much!