1974037 - Starting vertical tab drag right before expand on hover leaves tabs looking unexpanded

Status: VERIFIED FIXED

(Firefox :: Sidebar, defect, P1)

Description

[Stephen Thompson [:sthompson]]

Attachment: Video showing the bug reproduced when quickly moving the mouse

Found in

• Nightly 142.0a1 (2025-06-24) (aarch64)

Affected platforms

• All

Steps to reproduce

1. Pin some tabs.
2. Enable the Vertical Sidebar.
3. Enable the Expand sidebar on hover option.
4. Select multiple unpinned tabs
5. Move the mouse cursor outside of the tab strip so that the sidebar collapses
6. Very quickly move the mouse cursor over one of the multi-selected tabs, left click, and start dragging

Expected result

• The vertical tab strip should automatically expand and the tabs in the tab strip (both the non-moving tabs and the moving tabs) should be expanded to take up the full width of the tab strip

Actual result

• The vertical tab strip automatically expands but the tabs in the tab strip (both the non-moving tabs and the moving tabs) keep their unexpanded width, leaving a lot of empty space in the tab strip

Regression range
This issue comes with the new Drag and Drop into the pinned section feature.

Comment 1

[Stephen Thompson [:sthompson]]

You do need to move quickly to get into this state, so I don't think the severity is super high.

It looks to me like this manifests only when the dragstart event gets handled by <tabs> before the sidebar has a chance to change to the expanded state.

I suspect the issue is caused by all tabs getting their max-width fixed https://searchfox.org/mozilla-central/rev/ec8a326713f60dec138a3e3383b03ac739870fc7/browser/components/tabbrowser/content/tabs.js#2196 Thinking about it, maybe this only needs to be applied to tabs in the horizontal tab strip? That may be sufficient to fix this issue without causing any regressions or issues for horizontal.

If there is a reason to keep tab strip items' widths capped during vertical tab strip drags, then the <tabs> element may need to be aware of tab strip width changes and update the max-width of non-moving tabs and both the width and max-width for moving tabs.

Comment 2

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

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

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

For more information, please visit BugBot documentation.

Comment 3

[Pascal Chevrel:pascalc]

Will that bug be fixed in time for a 141 uplift or are we targeting a later release? Thanks

Comment 4

[Sarah Clements [:sclements] | PTO until March 30th]

(In reply to Pascal Chevrel:pascalc from comment #3)

Will that bug be fixed in time for a 141 uplift or are we targeting a later release? Thanks

We're likely targeting 142.

Comment 5

[Jonathan Sudiaman [:jsudiaman]]

This appears to be a race condition between MozTabbrowserTabs.#updateTabStylesOnDrag, and SidebarController.onMouseEnter().

With logpoints on these functions, when the issue reproduces, the log is as follows:

onMouseEnter was called, waiting for task to complete.
movingTab width now becomes 49.633331298828125px
onMouseEnter task is complete.

vs. when the issue does not reproduce, the log is:

onMouseEnter was called, waiting for task to complete.
onMouseEnter task is complete.
movingTab width now becomes 242.11666870117188px

So, I believe this is caused by obtaining the bounding client rect during the delay between mouse enter and sidebar animation, therefore causing rect to have outdated data by the time we set movingTab.style.width.

Comment 6

[Jonathan Sudiaman [:jsudiaman]]

Attachment: Bug 1974037 - Fix tab width being shrunken down when expand on hover is enabled. r?#sidebar-reviewers,sthompson

The shorter delay doesn't seem noticeable, and with it in place, I was no longer able to reproduce the issue.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/b8a5a295179f
https://hg.mozilla.org/integration/autoland/rev/805b890cdc37
Fix tab width being shrunken down when expand on hover is enabled. r=tabbrowser-reviewers,nsharpley,sthompson

Comment 8

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/805b890cdc37

Comment 9

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

The patch landed in nightly and beta is affected.
:jsudiaman, 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-firefox143 to wontfix.

For more information, please visit BugBot documentation.

Comment 10

[Jonathan Sudiaman [:jsudiaman]]

Bug is fairly hard to reproduce and easy to work around.

Comment 11

[Dana Lucaci, Desktop QA]

Reproduced with Firefox 142.0a1 (2025-06-25) on macOS 15.
Verified as fixed with Firefox 145.0a1 (20250917161633) and Firefox 144.0b2 (20250917090643) on macOS 14, Windows 10 and Ubuntu 22.