Drag-drop tab group label leaves group collapsed if group is only thing in window
Categories
(Firefox :: Tabbed Browser, defect, P4)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr128 | --- | unaffected |
firefox139 | --- | unaffected |
firefox140 | + | fixed |
firefox141 | + | fixed |
People
(Reporter: sthompson, Assigned: sthompson)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: regression, Whiteboard: [fidefe-tabgrps-dnd])
Attachments
(1 file)
Nightly 141.0a1 (2025-05-28) (aarch64)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:141.0) Gecko/20100101 Firefox/141.0
Steps to reproduce:
- Create a tab group
- Ensure that the tab group is expanded, that the tab group is the only thing in the tab strip (no other groups or tabs), and that the active tab is inside of the tab group
- Left-click and hold on the tab group label the move the mouse very slightly to start dragging -- this will automatically collapse the tab group to make dragging easier
- Let go of the left mouse button to "drop" the tab group label in place
Actual results:
The tab group stays collapsed. The active tab is still inside of the collapsed tab group, but it's not visible on the tab strip. It's possible to click to expand the tab group, so this is a recoverable problem.
Expected results:
On drop, the tab group should re-expand
Updated•3 months ago
|
Assignee | ||
Comment 1•3 months ago
|
||
Assignee | ||
Comment 2•3 months ago
|
||
https://searchfox.org/mozilla-central/rev/932e5cded30452c4f009b4f9254021f8b9895217/browser/components/tabbrowser/content/tabs.js#1046 doesn't seem to get called in this scenario but should be a simple fix
Assignee | ||
Comment 3•3 months ago
|
||
I have a patch https://phabricator.services.mozilla.com/D249715 for bug 1964288 that should fix this. It seems like the previous fix for bug 1959350 also broke this behavior.
Comment 4•3 months ago
|
||
Set release status flags based on info from the regressing bug 1959350
:dao, since you are the author of the regressor, bug 1959350, could you take a look?
For more information, please visit BugBot documentation.
Assignee | ||
Updated•3 months ago
|
Updated•3 months ago
|
Comment 5•3 months ago
|
||
The bug is marked as tracked for firefox140 (beta) and tracked for firefox141 (nightly). However, the bug still isn't assigned, has low priority and has low severity.
:cbellini, could you please find an assignee, increase the priority 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.
Updated•3 months ago
|
Comment 6•3 months ago
|
||
Next week is the final week of beta for Fx140
(In reply to Stephen Thompson [:sthompson] from comment #3)
I have a patch https://phabricator.services.mozilla.com/D249715 for bug 1964288 that should fix this. It seems like the previous fix for bug 1959350 also broke this behavior.
Bug 1964288 has landed and will be uplifted to beta later today. :sthompson, is there any follow-up work needed here, or has Bug 1964288 also fixed this?
Assignee | ||
Comment 7•3 months ago
|
||
:dmeehan Sorry for the confusion. The patch for bug 1964288 landed on Nightly, that patch should have fixed this bug as well, and I can confirm that this bug is fixed on Nightly. Uplifting the patch for bug 1964288 should also fix this bug on Beta.
Is there a better way for me to flag this relationship between bugs in Bugzilla so that it's easier for release managers?
Comment 8•3 months ago
|
||
No worries, the relationship was good - i.e. bug 1964288 was set to depends on.
I'll mark this bug as resolved to clean it up.
Description
•