Closed Bug 1926120 Opened 4 days ago Closed 17 hours ago

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

Categories

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

defect

Tracking

()

RESOLVED FIXED
133 Branch
Tracking Status
firefox-esr115 --- unaffected
firefox-esr128 --- unaffected
firefox131 --- unaffected
firefox132 --- unaffected
firefox133 + fixed

People

(Reporter: mstange, Assigned: Gijs)

References

(Regression)

Details

(Keywords: regression, Whiteboard: [fidefe-sidebar])

Attachments

(6 files)

[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.

(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.

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.

: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.

Flags: needinfo?(nsharpley)

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...

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.

Severity: -- → S3
Flags: needinfo?(nsharpley)
Keywords: blocked-ux
Priority: -- → P2
Whiteboard: [fidefe-sidebar]

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.

Flags: needinfo?(pluk)
Flags: needinfo?(pluk)

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.

(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.

See Also: → 1925257
Priority: P2 → P1
Summary: It has become harder to click tabs in full screen mode, tab bar covered by a gray bar → Revert bug change from 1921819 since its harder to click tabs in full screen mode
Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Duplicate of this bug: 1926577
No longer duplicate of this bug: 1926577
Attached video light-animation.mov
Attached video dark-animation.mov
Pushed by gijskruitbosch@gmail.com: 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
Status: ASSIGNED → RESOLVED
Closed: 17 hours ago
Resolution: --- → FIXED
Target Milestone: --- → 133 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: