1926120 - Revert bug change from 1921819 since its harder to click tabs in full screen mode

Status: VERIFIED FIXED

(Firefox :: Toolbars and Customization, defect, P1)

Description

[Markus Stange [:mstange]]

Attachment: screen recording with horizontal tabs

[Tracking Requested - why for this release]: Usability regression on macOS

This regression was caused by bug 1921819, which effectively re-introduced bug 738335.

Steps to reproduce:

1. Have a few tabs open, with horizontal tabs (default).
2. Press the green window button to make the window fullscreen.
3. Using the mouse, try to switch to a different tab. But on the way to the tab, overshoot past the tab and hit the top edge of the screen.

Expected results:
You should be able to click the tab.

Actual results:
When the mouse hits the top edge of the screen, a gray bar appears which now covers the tabs. The tabs can no longer be clicked. You have to move your mouse down, wait, and move it carefully back up.

I'm seeing this on macOS 15.0.1, on the internal screen of a Macbook Pro with a notch.

---

I didn't fully follow the conversation that came to this conclusion - the Slack link in bug 1921819 comment 33 doesn't work for me.

However, I think the goal was to avoid visual imperfections. I believe the visual imperfections are not as serious as the usability impact from not being able to click tabs / buttons at the top of the window unless you move the mouse very carefully.

Comment 1

[Markus Stange [:mstange]]

Attachment: screen recording with vertical tabs

Comment 2

[:Gijs (out for now; he/him)]

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

I didn't fully follow the conversation that came to this conclusion - the Slack link in bug 1921819 comment 33 doesn't work for me.

However, I think the goal was to avoid visual imperfections.

No. I summarized the slack discussion in phabricator, but to copy-paste again, the UX person involved wrote:

The main reason overlapping the navigation toolbar is preferable to moving the entire toolbar is to reduce the amount of visual movement and disruption to the user’s workflow. Overlapping the sidebar with the title bar + toolbar looks broken and like a mistake to me. Other browsers and many macOS apps, including Slack, Calendar, and the Music App, already use this behavior—where the title bar with controls overlaps content upon hover rather than shifting the UI down. This consistency with other applications helps users feel more comfortable and reduces the learning curve.

I'll pass your feedback along.

Comment 3

[Markus Stange [:mstange]]

Thanks! To me this sounds like the intended behavior was to not have a bar that overlaps the window, but instead just show the window buttons. But that's not possible with the current implementation.

Comment 4

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

:nsharpley, since you are the author of the regressor, bug 1921819, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 5

[Emilio Cobos Álvarez (:emilio)]

FWIW apparently we have some configurations where we currently get the wrong shift, see this.

I think we should just show the buttons in full-screen and have the nav bar not overlap... But yeah that needs widget work... Can try to look into it some time but if there's other people with cycles please do...

Comment 6

[Sarah Clements [:sclements]]

This is a regression but since it needs UX input and possibly widget work as Emilio alluded to, marking it as a P2/S3 for now - especially timing is tight for addresssing in 133.

Comment 7

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

The bug is marked as tracked for firefox133 (nightly). We have limited time to fix this, the soft freeze is in 2 days. However, the bug still isn't assigned and has low severity.

:pluk, could you please find an assignee and increase the severity for this tracked bug? Given that it is a regression and we know the cause, we could also simply backout the regressor. If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Comment 8

[Emilio Cobos Álvarez (:emilio)]

FWIW, I looked into how chrome hides the animation and it's not super clear to me but they seem to be using an NSToolbar:

https://source.chromium.org/chromium/chromium/src/+/main:components/remote_cocoa/app_shim/immersive_mode_tabbed_controller_cocoa.mm;l=113-122;drc=afa45afbcbba726830b338422a4c382ba417e353

Comment 9

[:Gijs (out for now; he/him)]

OK, Yulia, Emilio and I met to discuss this. It seems that the "right" solution of suppressing the macOS animation is very non-trivial, so not a solution we are able to pursue for 133.

Given the constraints, the tight timeframe, and the amount of feedback in 738335 and the dupes, we have decided that we will:

• revert the change from 1921819
• add some class/z-index logic to ensure that the navtoolbox (tabstrip + toolbar + bookmarks toolbar, as applicable) gets a shadow (so it's clear it overlaps web content + any sidebars)

This is not really a "great" solution - as outlined in comment 2, there is a lot of movement and this isn't great for the user either - but it is the one available to us in the timeframe that we have, and it seems preferable over the current mozilla-central state.

Comment 10

[:Gijs (out for now; he/him)]

(In reply to :Gijs (he/him) from comment #9)

It seems that the "right" solution of suppressing the macOS animation is very non-trivial, so not a solution we are able to pursue for 133.

This is covered in bug 1925257.

Comment 12

[:Gijs (out for now; he/him)]

Attachment: system-light-with-tabs.mov

Comment 13

[:Gijs (out for now; he/him)]

Attachment: light-animation.mov

Comment 14

[:Gijs (out for now; he/him)]

Attachment: dark-animation.mov

Comment 15

[:Gijs (out for now; he/him)]

Attachment: Bug 1926120 - go back to also moving the toolbox in macOS fullscreen menubar animation, and add a border/shadow, r?#desktop-theme-reviewers

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e509c25e4ec7
go back to also moving the toolbox in macOS fullscreen menubar animation, and add a border/shadow, r=desktop-theme-reviewers,emilio

Comment 17

[Cristian Tuns]

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

Comment 18

[Ada C.]

I was able to reproduce the issue on macOS 13.6 ARM using Firefox build 133.0a1 (2024-10-21).
Verified as fixed on macOS 13.6 ARM using Firefox build 134.0a1 and 133.0b9.