Closed Bug 1969163 Opened 3 months ago Closed 3 months ago

Drag-drop tab group label leaves group collapsed if group is only thing in window

Categories

(Firefox :: Tabbed Browser, defect, P4)

Firefox 140
defect

Tracking

()

RESOLVED FIXED
141 Branch
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

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.

Keywords: regression
Regressed by: 1959350

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.

Flags: needinfo?(dao+bmo)
Depends on: 1964288

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.

Flags: needinfo?(cbellini)
Assignee: nobody → sthompson
Flags: needinfo?(cbellini)

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?

Flags: needinfo?(sthompson)

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

Flags: needinfo?(sthompson)

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.

Status: NEW → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → 141 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: