Closed Bug 1748640 Opened 2 years ago Closed 2 years ago

[macOS] Controls bar covers tab bar in fullscreen mode when the mouse is moved on the top of the screen

Categories

(Core :: Widget: Cocoa, defect, P2)

Firefox 97
Desktop
macOS
defect

Tracking

()

VERIFIED FIXED
98 Branch
Tracking Status
firefox-esr91 --- unaffected
firefox95 --- unaffected
firefox96 --- unaffected
firefox97 --- verified
firefox98 --- verified

People

(Reporter: atrif, Assigned: emilio)

References

(Regression)

Details

(Keywords: regression)

Attachments

(3 files)

Affected versions

  • 97.0a1 (20220105093353)

Affected platforms

  • macOS 10.15
  • macOS 10.14 and 10.13
  • macOS 12.1 and 11.6 (issue is more intermittent)

Steps to reproduce

  1. Open Firefox and enable the title bar.
  2. Enter fullscreen and move the mouse on top of the screen.

Expected result

  • Title bar is displayed as expected over the tab bar.

Actual result

  • Tile bar overlaps tab bar.

Regression range

Notes

  • Screen recording attached here.
  • Note that the issue may be intermittent.
  • This happens with native fullscreen enabled as well.
  • I cannot reproduce the issue on macOS 11 M1 mini for some reason. This can be reproduced on macOS 11 M1 mini as well but the issue is more intermittent.
Has Regression Range: --- → yes
Has STR: --- → yes
Keywords: regression
Regressed by: 1737831

On 16" MacBook Pro with notch I could not reproduce the issue with "standard" Fullscreen settings, but I could reproduce it by setting the Firefox application to "Scale to fit below built-in camera" (Get Info -> general settings) and by moving the mouse to the top to trigger the menu scroll-down as the window is still getting maximized.

With "Scale to fit below built-in camera" it's possible to trigger the scroll-down of the menu basically as the window is still getting maximized, which I assume it's the underlying cause of the issue. Without the "Scale to fit below built-in camera" setting I was unable to trigger the scroll-down fast enough so I'm unsure if there is still an underlying bug in the logic which cannot or is more difficult to trigger due to the different way MacOS handles the Fullscreen.

I assume on a notch-less display the issue arises the same way as in a notched display with "Scale to fit below built-in camera".

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

(In reply to Christian Apolloni from comment #1)

On 16" MacBook Pro with notch I could not reproduce the issue with "standard" Fullscreen settings, but I could reproduce it by setting the Firefox application to "Scale to fit below built-in camera" (Get Info -> general settings) and by moving the mouse to the top to trigger the menu scroll-down as the window is still getting maximized.

I don't have such device, can you grab a recording of that please? The bug that regressed this assumed that the menubar always took the notch space, but maybe that's not right...

I assume on a notch-less display the issue arises the same way as in a notched display with "Scale to fit below built-in camera".

I haven't been able to repro on the latest nightly on a MBP 2018 with default settings, nor with the "automatically hide and show the menu bar in full screen"... Do you know how can I repro on such machine? It's the only Mac I have around :-/

Flags: needinfo?(emilio) → needinfo?(alexandru.trif)

Video reproducing the issue with 16" MacBook Pro with a notch.

  • Firefox Nightly is configured with the option "Scale to fit below built-in camera": this makes the fullscreen mode behave as if the screen has no notch and uses the screen estate below the notch to display the menu bar when the mouse moves to the top.

  • First part of the video is by moving the mouse very fast to the top, reproducing the issue: the drop-down part overlaps with the tab bar.

  • Second part is by moving the mouse to the top after waiting a few seconds: the drop-down part does not overlap the tab bar anymore, which is moved downwards as the drop-down part appears.

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

I don't have such device, can you grab a recording of that please? The bug that regressed this assumed that the menubar always took the notch space, but maybe that's not right...

See Comment 3.

I haven't been able to repro on the latest nightly on a MBP 2018 with default settings, nor with the "automatically hide and show the menu bar in full screen"... Do you know how can I repro on such machine? It's the only Mac I have around :-/

I was also unable to reproduce the issue on a 16" MacBook Pro without notch. The reporter stated it happens sporadically but I tried multiple times to reproduce without success. I can reproduce it consistently on the 16" with notch as described above.

If you need me to test some tentative fix I'm able to build Firefox on my machine with notch and provide you with feedback about it, but if the issue is only with the "Scale to fit below built-in camera" I question how really a priority it is: I guess it's not a very common option to have enabled.

Thanks. If you're able to build in your machine, I can point to the relevant code. The relevant code is this. Right now we never shift the menubar height if the screen has a notch, but we need to if that particular setting is set, presumably. So the question becomes what is the right check.

I think ideally that condition should just be if (!gMenubarAlwaysShownInFullScreen), but that reportedly wasn't enough to get the right behavior, according to bug 1737831 comment 19. Maybe we can check menubarVisible at a different point in time, or maybe the person that commented didn't test the right build? Or perhaps we can read the system setting somehow, I'm not sure.

Thinking about it a bit more, given it only happens if you move the mouse to the top "fast", that probably just means that gMenubarAlwaysShownInFullScreen is (incorrectly) true when you reproduce the issue, since presumably it's showing already.

So I wonder if we can compute that at a better time or something. Or perhaps get the actual height from the accessory view (https://developer.apple.com/documentation/appkit/nstitlebaraccessoryviewcontroller?language=objc). But not an expert here. Harry, do you have any suggestions?

Flags: needinfo?(htwyford)

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

I haven't been able to repro on the latest nightly on a MBP 2018 with default settings, nor with the "automatically hide and show the menu bar in full screen"... Do you know how can I repro on such machine? It's the only Mac I have around :-/

Hello! After looking into this today it seems that this does not need the Title Bar active to reproduce (screen recording). I can reproduce this without the title bar with Firefox 97.0a1 (2022-01-09) on MacBook Pro 13-inch, 2017, and iMac 21.5-inch 2013 both having macOS 10.15. On the same MacBook Pro, I can reproduce the issue on macOS 10.13 and 10.14 as well without activating the Title Bar. We can reproduce this on macOS 11.6 Mac M1 mini as well and on MacBook pro-mid-2015 with macOS 12.1, but the issue is more intermittent on these two macOS versions. What I've noticed is that the issue reproduces only if it's reproduced the first time entering fullscreen, so basically, the steps are:

  1. Open Firefox and enter fullscreen.
  2. Move the mouse to the top of the screen.
    If the issue is not reproduced, we need to exit fullscreen, enter fullscreen and move the mouse on the top of the screen again. I cannot reproduce this if it does not reproduce the first time entering fullscreen. It can be reproduced using CMD+ Shift+ F to enter/ exit fullscreen and keeping the mouse on top of the screen while using the keyboard to enter/ exit fullscreen multiple times.

Raising the Severity as well because this can be reproduced without Title Bar. If any more information is needed please let me know.

Severity: S3 → S2
Flags: needinfo?(alexandru.trif)
Summary: [macOS] Title bar covers tab bar in fullscreen mode → [macOS] Controls bar covers tab bar in fullscreen mode when the mouse is moved on the top of the screen

I still haven't able to repro though I'm in 12.2 beta. If you go to "System preferences -> Dock and menubar" in macOS 10.5, is there an "Automatically hide and show the menu bar in full screen" option? If not we might as well not try to detect that option and do a version check to keep the previous behavior untouched.

Flags: needinfo?(alexandru.trif)

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

I still haven't able to repro though I'm in 12.2 beta. If you go to "System preferences -> Dock and menubar" in macOS 10.5, is there an "Automatically hide and show the menu bar in full screen" option? If not we might as well not try to detect that option and do a version check to keep the previous behavior untouched.

These are the only options that are inside macOS 10.15 System Preferences-> Dock (screenshot). I can't find the "Automatically hide and show the menu bar in full screen" option. Only "Automatically show and hide the menu bar" inside General and "Automatically show and hide the dock" inside Dock settings. Also, note that we could reproduce this in macOS 12.1 and 11.6 but the issue is really intermittent there. I will ask a colleague of mine to attach a screen recording on macOS 12.1 including macOS settings as well, maybe it helps.

Flags: needinfo?(alexandru.trif)

Here is a recording of the issue on Firefox 97.0a1 under macOS 12.1. It is reproducible with or without title bar active.

Blocks: 1749589

I can regularly reproduce this bug in Split View mode. I filed bug 1749589 for that issue, but I think both this bug and that one have the same root cause.

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

Or perhaps get the actual height from the accessory view (https://developer.apple.com/documentation/appkit/nstitlebaraccessoryviewcontroller?language=objc). But not an expert here. Harry, do you have any suggestions?

Unfortunately, the revealAmount API we use to get the height of the menu bar is undocumented, so I don't have any great ideas. I'll do some research.

(In reply to Harry Twyford [:harry] from comment #10)

I can regularly reproduce this bug in Split View mode. I filed bug 1749589 for that issue, but I think both this bug and that one have the same root cause.

I tried to reproduce the issue in Split View on MacOS 12.1 on a 16" MacBook Pro with notch on 97.0a1 and was unable to, either with or without the "scale to fit below built-in camera" option.

Assignee: nobody → emilio
Flags: needinfo?(htwyford)

(err, sorry, didn't intend to cancel ni?)

Flags: needinfo?(htwyford)
Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/796925ce4e12
Revert behavior change from bug 1737831 on notch-less macbooks, and add a pref to control this behavior. r=mac-reviewers,bradwerth
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 98 Branch

Comment on attachment 9258578 [details]
Bug 1748640 - Revert behavior change from bug 1737831 on notch-less macbooks, and add a pref to control this behavior. r=spohl,#mac-reviewers

Beta/Release Uplift Approval Request

  • User impact if declined: Comment 0
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: QA has been able to repro this (I haven't :))
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Reverts to previous behavior trivially
  • String changes made/needed: none
Attachment #9258578 - Flags: approval-mozilla-beta?
Flags: qe-verify+

On my MacBook Pro 16" with notch these are my results with the new Pref widget.macos.shift-by-menubar-on-fullscreen:

  • Pref default was 2 and activates the new behaviour, preventing the extra space to appear.
  • Setting the Pref to 1 activates the original behaviour, leading to the extra space appearing again.
  • Setting the Pref to 0 acts like 2, activates the new behaviour, preventing the extra space to appear.
QA Whiteboard: [qa-triaged]

Verified this on macOS 10.15, 10.13, 10.14 and 11.6 M1 mini with Firefox 98.0a1 (20220112213002) using widget.macos.shift-by-menubar-on-fullscreen pref:

  • default pref on 2 (auto)= cannot reproduce the reported issue
  • setting pref to 1 (always)= cannot reproduce the reported issue
  • setting pref to 0 (never)= can reproduce the reported issue

Comment on attachment 9258578 [details]
Bug 1748640 - Revert behavior change from bug 1737831 on notch-less macbooks, and add a pref to control this behavior. r=spohl,#mac-reviewers

Approved for 97.0b3.

Flags: needinfo?(htwyford)
Attachment #9258578 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

(In reply to Alexandru Trif, QA [:atrif] from comment #18)

Verified this on macOS 10.15, 10.13, 10.14 and 11.6 M1 mini with Firefox 98.0a1 (20220112213002) using widget.macos.shift-by-menubar-on-fullscreen pref:

  • default pref on 2 (auto)= cannot reproduce the reported issue
  • setting pref to 1 (always)= cannot reproduce the reported issue
  • setting pref to 0 (never)= can reproduce the reported issue

Verified on all above macOS systems with Firefox 97.0b3 and the issue is no longer reproducing.

Christian if you have the time can you please verify this issue like in comment 17 on MacBook Pro 16" with notch using the latest Firefox beta as well? Thank you in advance.

Flags: needinfo?(christian.apolloni)

(In reply to Alexandru Trif, QA [:atrif] from comment #21)

Christian if you have the time can you please verify this issue like in comment 17 on MacBook Pro 16" with notch using the latest Firefox beta as well? Thank you in advance.

Tested 97.0b3 on MacBook Pro 16" with notch, with the same results as in comment #17.

I also tried to test with the "Scale to fit below the built-in camera" option enabled but it seems to have no effect for some reason on 97.0b3. The option does work with 98.0a1 (2022-01-13), with the following results:

  • Pref default 2 and works correctly (no extra space, no overlaps)
  • Setting the Pref to 1 works like 2.
  • Setting the Pref to 0 causes the drop-down to overlap.
Flags: needinfo?(christian.apolloni)

(In reply to Christian Apolloni from comment #22)

(In reply to Alexandru Trif, QA [:atrif] from comment #21)

Christian if you have the time can you please verify this issue like in comment 17 on MacBook Pro 16" with notch using the latest Firefox beta as well? Thank you in advance.

Tested 97.0b3 on MacBook Pro 16" with notch, with the same results as in comment #17.

Thank you!

I also tried to test with the "Scale to fit below the built-in camera" option enabled but it seems to have no effect for some reason on 97.0b3. The option does work with 98.0a1 (2022-01-13), with the following results:

  • Pref default 2 and works correctly (no extra space, no overlaps)
  • Setting the Pref to 1 works like 2.
  • Setting the Pref to 0 causes the drop-down to overlap.

Emilio do you have some thoughts here? From my understanding, the widget.macos.shift-by-menubar-on-fullscreen pref does not work with the "Scale to fit below the built-in camera" option enabled on 97.0b3 but it works on the latest nightly.

Flags: needinfo?(emilio)

(In reply to Alexandru Trif, QA [:atrif] from comment #23)

Emilio do you have some thoughts here? From my understanding, the widget.macos.shift-by-menubar-on-fullscreen pref does not work with the "Scale to fit below the built-in camera" option enabled on 97.0b3 but it works on the latest nightly.

No, the "Scale to fit below the built-in camera" itself does not work with 97.0b3, meaning that the application works as if the option is deactivated even if I activate it. This means I cannot even test the Pref widget.macos.shift-by-menubar-on-fullscreen with it.

I'm not sure why since it's a compatibility option that I expect to be handled at the OS level. It's also strange that it works with Nightly and not with Beta.

Later I will try to restart the system, maybe it will fix the issue and I will be able to test that combination too.

(In reply to Christian Apolloni from comment #24)

(In reply to Alexandru Trif, QA [:atrif] from comment #23)

Emilio do you have some thoughts here? From my understanding, the widget.macos.shift-by-menubar-on-fullscreen pref does not work with the "Scale to fit below the built-in camera" option enabled on 97.0b3 but it works on the latest nightly.

No, the "Scale to fit below the built-in camera" itself does not work with 97.0b3, meaning that the application works as if the option is deactivated even if I activate it. This means I cannot even test the Pref widget.macos.shift-by-menubar-on-fullscreen with it.

I'm not sure why since it's a compatibility option that I expect to be handled at the OS level. It's also strange that it works with Nightly and not with Beta.

Later I will try to restart the system, maybe it will fix the issue and I will be able to test that combination too.

It is indeed strange that this works with Nightly and with beta does not work. I will clear the ni? request then. If you can please post the results after the restart. Thank you!

Flags: needinfo?(emilio)

(In reply to Alexandru Trif, QA [:atrif] from comment #25)

It is indeed strange that this works with Nightly and with beta does not work. I will clear the ni? request then. If you can please post the results after the restart. Thank you!

A restart didn't help but I somehow managed to test by putting Firefox 97.0b3 and 98.0a1 in fullscreen split-screen mode with 98.0a1 having the "Scale to fit below the built-in camera" active. This causes all other applications sharing the fullscreen with it to also be scaled below the built-in camera.

With the setup above 97.0b3 behaves like 98.0a1 (2022-01-13): correct with 2 (default), correct with 1, overlapping with 0.

Closing this based on the above comments. Thanks again Christian for all the testing performed.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
No longer blocks: 1749589
Regressions: 1815099
No longer regressions: 1815099
See Also: → 1815099
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: