1956394 - Tab groups are misaligned when using expand on hover with vertical tabs

Status: VERIFIED FIXED

(Firefox :: Tabbed Browser, defect, P1)

Description

[patrice.grundmann]

Attachment: 2025-03-26_02-30-46 copie.jpg

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:138.0) Gecko/20100101 Firefox/138.0

Steps to reproduce:

Install Firefox Nightly.
Create some tabs, and some tabs groups.

Actual results:

The hover effect since it appear (the 20 march) in Nightly is very disturbing. Visual focus is lost between the favicon (with the tab folded) and its unfolded version, when there's a hover effect on the favicon.

Expected results:

The expected behavior, if there is already the possibility of visually finding one's way around tabs, would be that the display should be identical and persist regardless of whether the tabs are “open” or “closed”. Take a look at Microsoft Edge to see for yourself.

Here is the bug in a image (two screencaps). I have drawn red dotted lines to visualise the problem.

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Firefox::Sidebar' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Sarah Clements [:sclements]]

Its not clear to me what the issue is - is it the misalignment with collapsed tabs vs expanded?

Do you have expand on hover enabled with vertical tabs? Do you also see this issue without tab groups?

Comment 3

[patrice.grundmann]

Hello,

Yes, it's an alignment problem. The tabs should be the same height and displayed where you expect them to be. The user looks at the favicon of the retracted tab, but when he hovers over it with the mouse, the tab appears lower than expected. This is very uncomfortable to use.

So, in effect, is hover development enabled with vertical tabs and this problem only arises with the presence of tab groups. If only tabs are used, with no groups, they are placed one under the other and displayed as expected.

Regards

Comment 4

[Sarah Clements [:sclements]]

Thanks for clarifying. Expand on hover is a new feature so this probably just requires a small change by the tab groups team to fix the alignment.

Comment 5

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

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

For more information, please visit BugBot documentation.

Comment 6

[patrice.grundmann]

The bug still exists, but it looks now better.

I don't know how to precise de severity. I have try to edit the first message.

Comment 7

[Stephen Thompson [:sthompson]]

:amlee could you please check Nightly with the following setup/prefs and provide feedback on what our team should fix?

• sidebar.verticalTabs = true
• sidebar.expandOnHover = true
• tab strip includes tab groups with grouped tabs and visible favicons

At a glance, the expanded state has a wider left gutter before the tab group hairline and the tab group label takes up more vertical space.

Comment 8

[patrice.grundmann]

Yes :sthompson I confirm all.

Comment 9

[Amy Lee [:amylee] UX]

Hi,

I think part of the issue is the transition between collapsed and expanded sidebar isn't to spec and is janky. There's currently no animation sliding between the 2 states. I had previously filed a bug for this below.

https://bugzilla.mozilla.org/show_bug.cgi?id=1959264

Comment 10

[Stephen Thompson [:sthompson]]

Attachment: Bug 1956394 - vertical tab groups label should always have same height r=dao,dwalker,jswinarton

The tabs in the vertical tab strip always have the same height regardless of whether the sidebar is collapsed or expanded. When expand-on-hover is enabled, it's easy to see that the tabs only change in width as you go back and forth from collapsed to expanded.

The tab group label element is using a line-height of 18px when expanded plus 4px block padding, totalling 26px high. When the sidebar is collapsed, the tab group label's first letter uses 24px line height and the label has no padding, totalling 24px high. When you expand the sidebar, everything below a tab group label appears to shift down by 2px, and this compounds for every tab group label in the tab strip.

This patch makes the tab group label element box take up 24px in height with default UI density and compact UI density. With touch UI density, tab group labels are 27px tall with expanded sidebar and 28.5px tall with collapsed sidebar. Negative padding would be required for the expanded case, but the padding is 0.

As a result, tabs and tab group labels now always retain their vertical positions and heights when transitioning between expanded sidebar and collapsed sidebar. The one exception is when the user has touch UI density with browser.uidensity = 2

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/8e679d9052f3
vertical tab groups label should always have same height r=dao,desktop-theme-reviewers,tabbrowser-reviewers

Comment 12

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/8e679d9052f3

Comment 13

[patrice.grundmann]

I wasn't sure about the Nightly deployment. Because I contend that the work is only partial. Hovering on reduced tabs doesn't necessarily display as well as on Edge, for example. I think it's the containers that are messing things up. They need to add some kind of padding, or something similar. In short, hovering over reduced tabs makes them display lower and more to the right. They sort of ripple.

Comment 14

[patrice.grundmann]

In fact, I have 12 groups of tabs, and the shift occurs towards the end of the list of these groups. When you hover over a tab group, aiming at the middle of its height, the sidebar unfolds and the cursor is at the bottom of its label. There's an offset.

Comment 15

[patrice.grundmann]

Here is the gap example: https://ibb.co/xqBbYrbF

Comment 16

[Dão Gottwald [:dao]]

Hey Patrice, could you please file a separate followup bug for the remaining issue you found? That will make it easier to separate concerns and keep track of the patch that has landed here. Thanks!

Comment 17

[patrice.grundmann]

Well, I'm not lazzy to recreate a bug report… https://bugzilla.mozilla.org/show_bug.cgi?id=1964923

Comment 18

[Rares Doghi, Desktop QA]

This issue is Verified as fixed in our latest Nightly 140.0a1 (2025-05-12)

Comment 19

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

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

• If yes, please nominate the patch for beta approval.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox139 to wontfix.

For more information, please visit BugBot documentation.

Comment 20

[Rares Doghi, Desktop QA]

Updating the remaining flags.