Dragging tab to move within a tab group causes other tabs to jitter
Categories
(Firefox :: Tabbed Browser, defect, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr128 | --- | unaffected |
| firefox-esr140 | --- | unaffected |
| firefox139 | --- | unaffected |
| firefox140 | --- | unaffected |
| firefox141 | --- | unaffected |
| firefox142 | --- | verified |
| firefox143 | --- | verified |
People
(Reporter: nayinain, Assigned: sthompson)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: regression, Whiteboard: [fidefe-sidebar])
Attachments
(3 files)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:141.0) Gecko/20100101 Firefox/141.0
Steps to reproduce:
- Open multiple tabs within a tab group.
- Drag one of the tabs to move.
Actual results:
Other tabs to jitter.
Expected results:
Should not jitter.
Sorry for my bad English.
Regression window:
2025-06-19T01:34:17.699000: INFO : application_version: 141.0a1
2025-06-19T01:34:17.699000: INFO : platform_buildid: 20250615003026
2025-06-19T01:34:17.699000: INFO : platform_changeset: fdd655561d6df0b7b96450a0aa34eb7e964e2f0a
2025-06-19T01:34:17.699000: INFO : platform_repository: https://hg.mozilla.org/integration/autoland
2025-06-19T01:34:17.699000: INFO : platform_version: 141.0a1
2025-06-19T01:36:40.435000: INFO : Narrowed integration regression window from [559d4357, 4bfaf82b] (3 builds) to [559d4357, fdd65556] (2 builds) (~1 steps left)
2025-06-19T01:36:40.455000: DEBUG : Starting merge handling...
2025-06-19T01:36:40.456000: DEBUG : Using url: https://hg.mozilla.org/integration/autoland/json-pushes?changeset=fdd655561d6df0b7b96450a0aa34eb7e964e2f0a&full=1
2025-06-19T01:36:40.458000: DEBUG : redo: attempt 1/3
2025-06-19T01:36:40.459000: DEBUG : redo: retry: calling _default_get with args: ('https://hg.mozilla.org/integration/autoland/json-pushes?changeset=fdd655561d6df0b7b96450a0aa34eb7e964e2f0a&full=1',), kwargs: {}, attempt #1
2025-06-19T01:36:40.466000: DEBUG : urllib3.connectionpool: Resetting dropped connection: hg.mozilla.org
2025-06-19T01:36:43.002000: DEBUG : urllib3.connectionpool: https://hg.mozilla.org:443 "GET /integration/autoland/json-pushes?changeset=fdd655561d6df0b7b96450a0aa34eb7e964e2f0a&full=1 HTTP/11" 302 0
2025-06-19T01:36:43.008000: DEBUG : urllib3.connectionpool: Resetting dropped connection: hg-edge.mozilla.org
2025-06-19T01:36:47.209000: DEBUG : urllib3.connectionpool: https://hg-edge.mozilla.org:443 "GET /integration/autoland/json-pushes?changeset=fdd655561d6df0b7b96450a0aa34eb7e964e2f0a&full=1 HTTP/11" 200 None
2025-06-19T01:36:47.211000: DEBUG : Found commit message:
Bug 1944907 - Drag a tab to pin or unpin it r=sidebar-reviewers,desktop-theme-reviewers,tabbrowser-reviewers,dao,kcochrane,sthompson,mconleyDifferential Revision: https://phabricator.services.mozilla.com/D247132
2025-06-19T01:36:47.212000: DEBUG : Did not find a branch, checking all integration branches
2025-06-19T01:36:47.216000: INFO : The bisection is done.
2025-06-19T01:36:47.217000: INFO : Stopped
Comment 2•9 months ago
|
||
: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•9 months ago
|
||
I was able to reproduce the issue as New on Win11x64 using Firefox build 141.0a1.
Mark issue as new.
Comment 4•9 months ago
|
||
Set release status flags based on info from the regressing bug 1944907
Updated•8 months ago
|
Updated•8 months ago
|
Comment 5•8 months ago
|
||
Set release status flags based on info from the regressing bug 1944907
Comment 6•8 months ago
|
||
Stephen, we're thinking of targeting 142 for a fix - any concerns with that?
| Assignee | ||
Comment 7•8 months ago
|
||
It's a minor visual glitch, so that's OK. It looks visually similar to bug 1975145, so they may have the same cause.
Updated•8 months ago
|
Comment 8•8 months ago
|
||
Assigning for Stephen to take a look and to report back findings.
| Assignee | ||
Comment 9•8 months ago
|
||
Ubuntu 24.04 on X11, horizontal tab strip only
Dragging an ungrouped tab when not overflowing causes the new tab button to shift by a pixel or two.
Dragging a grouped tab when not overflowing causes many tabs (both grouped and ungrouped) to jump for a few frames before settling back to their expected positions.
When overflowing, none of these issues appear.
If I call _lockTabSizing() in updateTabStylesOnDrag (replacing the existing "locking" code at https://searchfox.org/mozilla-central/rev/162a9137664040430d01d15c4a9be41c331c09ac/browser/components/tabbrowser/content/tabs.js#2175-2183) and _unlockTabSizing in resetTabsAfterDrop, the bad behavior disappears. That makes me think that setting transition: none, flushing the document, and then unsetting transition on the next frame is solving the jitter https://searchfox.org/mozilla-central/rev/162a9137664040430d01d15c4a9be41c331c09ac/browser/components/tabbrowser/content/tabs.js#2074-2095
tabs do have a max-width 100ms ease-out transition and therefore changes to max-width would animate... but I don't know why that's not happening on macOS and I don't know why the effect would be different when dragging an ungrouped tab vs. a grouped tab.
| Assignee | ||
Comment 10•8 months ago
|
||
This fixes a number of issues with tabs briefly shifting on dragstart in the horizontal, non-overflowing tab strip.
My guess is that clamping max-width on all tabs is insufficient, and the transition suppression in _lockTabSizing is fixing these problems.
Do you have any concerns about reusing the existing lock and unlock methods for this purpose?
For a real patch, I would check through the existing usages (like when dragging tab groups) so that we aren't calling lock/unlock multiple times unnecessarily. This is a proof of concept that is visually working for me in Linux.
Updated•8 months ago
|
Comment 11•8 months ago
|
||
If this is still targeting 142, just a friendly reminder that tomorrow is the start of soft code freeze.
Updated•7 months ago
|
Updated•7 months ago
|
Comment 12•7 months ago
|
||
Comment 13•7 months ago
|
||
| bugherder | ||
| Assignee | ||
Comment 15•7 months ago
|
||
This fixes a number of issues with tabs briefly shifting on dragstart in the horizontal, non-overflowing tab strip.
My guess is that clamping max-width on all tabs is insufficient, and the transition suppression in _lockTabSizing is fixing these problems.
This patch will lock the tab size on dragstart and unlock the tab size on either/both dragend and after drop animations have completed. For the specific case of dragging an expanded tab group, the tab group needs to be expanded only after the label animates into place.
Original Revision: https://phabricator.services.mozilla.com/D256934
Updated•7 months ago
|
Comment 16•7 months ago
|
||
firefox-beta Uplift Approval Request
- User impact if declined: Low. Visual glitch for Windows or Linux users when dragging tabs in the horizontal tab strip when the tab strip has a low number of tabs.
- Code covered by automated testing: no
- Fix verified in Nightly: yes
- Needs manual QE test: no
- Steps to reproduce for manual QE testing: Windows or Linux, horizontal tab strip, tab strip not overflowing: start dragging a tab. If the bug is fixed, the non-dragged tabs will maintain their positions and widths.
- Risk associated with taking this patch: Low/Medium
- Explanation of risk level: There has been a recent history of unintended regressions as a result of tab strip drag-drop patches. While this patch has been tested in Nightly, it's hard to feel super confident about these kinds of changes.
- String changes made/needed: No
- Is Android affected?: no
Updated•7 months ago
|
Updated•7 months ago
|
Comment 17•7 months ago
|
||
| uplift | ||
Updated•7 months ago
|
Updated•7 months ago
|
Updated•7 months ago
|
Comment 18•7 months ago
|
||
I was able to reproduce the issue in Nightly 141.0a1 on macOS 15. Verified in the latest Nightly 143.0a1 and Firefox 142.0 on Windows 10, macOS 15, and Ubuntu 20.04. The issue is no longer present when dragging tabs in a horizontal tab strip. Marking this as Verified Fixed.
Description
•