Allow drag-drop of tabs into collapsed tab groups
Categories
(Firefox :: Tabbed Browser, enhancement, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox143 | --- | verified |
People
(Reporter: sthompson, Assigned: sthompson)
References
(Blocks 1 open bug)
Details
(Whiteboard: [fidefe-tabgrps])
Attachments
(1 file, 2 obsolete files)
- Hover animation when dragging a tab onto a collapsed tab group label after a delay (similar to the "create tab group on drop" behavior when dragging one ungrouped tab over another)
- Dropping tabs "onto" the collapsed tab group label should drop the tabs into the group rather than next to the group
- When dragging the active tab and the active tab is in a collapsed tab group, fully collapse the group on dragstart. If the user hovers over the collapsed tab group label that the active tab was in + waits + drops, then the collapsed tab group should return to the collapsed-with-active-tab state. Additionally, the active tab should not move. In other words, this should act like "canceling" the drag operation to return to the original state.
UX spec: https://www.figma.com/design/f6J2lH6XDxLxyzOLr2E8oE/Tab-Grouping-Spec?node-id=19955-98738&t=JykDp7IXqXCID6bU-0
Animation demo: https://drive.google.com/file/d/15v3Yh0gaj0W8R5E--mnQcTpmnirIKo2L/view
Updated•6 months ago
|
| Assignee | ||
Updated•5 months ago
|
| Assignee | ||
Comment 1•5 months ago
|
||
Dragging a tab(s) and hovering it over a collapsed tab group label for a short duration will highlight the dragged tab(s) and the collapsed tab group label in order to indicate that dropping the tab(s) will put it into the group. Since the dragged tab is always the active tab, dropping the moving tab(s) into the collapsed tab group will cause the collapsed tab group to enter the "collapsed-but-with-active-tab" state.
If the active tab is in a collapsed tab group and you try to drag it, dropping the tab right away will drop it after the tab group. In order to "cancel" the operation and return the active tab to its prior position in the collapsed tab group, the user should drag the active tab back over the tab group label and hover over it until it highlights.
This patch wraps the tab group label in a second wrapper in order to provide the highlight color around the tab group label when hovering over a collapsed tab group label. Since this changes the markup and CSS positioning of the tab group label, there needed to be several adjustments in order to ensure that the labels maintain their dimensions and spacing.
This patch leverages the approach of the "create group" functionality + visuals when hovering an ungrouped tab(s) over another. I made the functionality + visuals a bit more generic by referring to it as "grouping" behavior.
The tab group label is supposed to grow by 4 pixels in both width and height when it's highlighted. Since CSS scale only operates on ratios, and since I did not find a way to use CSS to calculate the necessary scale, I am calculating + setting the required scale in JavaScript code.
This patch includes some necessary bug fixes:
- tab selection/tab activation can now cause a tab to appear or disappear if it's in a collapsed tab group, so
tabContainer.visibleTabsneeds to be updated if that happens - when dropping multiselected tabs into a collapsed tab group, the multiselected tabs need to be removed from multiselect since they become invisible
- moving an inactive tab into a collapsed tab group should not expand the tab group
| Assignee | ||
Comment 2•4 months ago
|
||
Dragging a tab(s) and hovering it over a collapsed tab group label for a short duration will highlight the dragged tab(s) and the collapsed tab group label in order to indicate that dropping the tab(s) will put it into the group. Since the dragged tab is always the active tab, dropping the moving tab(s) into the collapsed tab group will cause the collapsed tab group to enter the "collapsed-but-with-active-tab" state.
If the active tab is in a collapsed tab group and you try to drag it, dropping the tab right away will drop it after the tab group. In order to "cancel" the operation and return the active tab to its prior position in the collapsed tab group, the user should drag the active tab back over the tab group label and hover over it until it highlights.
This patch leverages the approach of the "create group" functionality + visuals when hovering an ungrouped tab(s) over another. I made the functionality + visuals a bit more generic by referring to it as "grouping" behavior.
The tab group label is supposed to grow by 4 pixels in both width and height when it's highlighted. Since CSS scale only operates on ratios, and since I did not find a way to use CSS to calculate the necessary scale, I am calculating + setting the required scale in JavaScript code.
If tab group A is collapsed and contains the active tab, and if the user starts dragging tab group B, then the "overflow counter" of tab group A will disappear for the duration of the drag operation. It would be possible to keep that element visible, but it would require opting that element into all of the drag-drop animation logic. That's too large of a change to include in this patch.
Tab selection/tab activation can now cause a tab to appear or disappear if it's in a collapsed tab group, so the <tabs> element's cache of visible tab strip items needs to be updated if that happens.
Updated•4 months ago
|
Comment 5•4 months ago
|
||
Reverted this because it was breaking the gecko decision task.
Comment 7•4 months ago
|
||
| bugherder | ||
| Assignee | ||
Updated•4 months ago
|
| Assignee | ||
Comment 8•4 months ago
|
||
Dragging a tab(s) and hovering it over a collapsed tab group label for a short duration will highlight the dragged tab(s) and the collapsed tab group label in order to indicate that dropping the tab(s) will put it into the group. Since the dragged tab is always the active tab, dropping the moving tab(s) into the collapsed tab group will cause the collapsed tab group to enter the "collapsed-but-with-active-tab" state.
If the active tab is in a collapsed tab group and you try to drag it, dropping the tab right away will drop it after the tab group. In order to "cancel" the operation and return the active tab to its prior position in the collapsed tab group, the user should drag the active tab back over the tab group label and hover over it until it highlights.
This patch leverages the approach of the "create group" functionality + visuals when hovering an ungrouped tab(s) over another. I made the functionality + visuals a bit more generic by referring to it as "grouping" behavior.
If tab group A is collapsed and contains the active tab, and if the user starts dragging tab group B, then the "overflow counter" of tab group A will disappear for the duration of the drag operation. It would be possible to keep that element visible, but it would require opting that element into all of the drag-drop animation logic. That's too large of a change to include in this patch.
Tab selection/tab activation can now cause a tab to appear or disappear if it's in a collapsed tab group, so the <tabs> element's cache of visible tab strip items needs to be updated if that happens.
Original Revision: https://phabricator.services.mozilla.com/D256745
Updated•4 months ago
|
Comment 9•4 months ago
|
||
firefox-beta Uplift Approval Request
- User impact if declined: Low/Medium. Without this patch, users can get stuck in an inconsistent tab strip state when attempting to drag the active tab when it starts in a collapsed tab group.
- Code covered by automated testing: no
- Fix verified in Nightly: yes
- Needs manual QE test: no
- Steps to reproduce for manual QE testing: Should be able to drag a tab over a collapsed tab group label and then drop it into the tab group after it highlights. Once the active tab is in a collapsed tab group, you should be able to drag the active tab out of the tab group and drop it elsewhere. The tab group should return to its fully-collapsed state.
- Risk associated with taking this patch: Low/Medium
- Explanation of risk level: In recent history, tab strip drag-drop changes have led to subtle regressions due to a lack of comprehensive automated test coverage and the difficulty of manually testing all variations of tab strip drag-drop behavior.
- String changes made/needed: No
- Is Android affected?: no
Updated•4 months ago
|
Comment 10•4 months ago
|
||
Approved, but adding qe verification as I felt this needed more eyes on it this late in the cycle.
Comment 11•4 months ago
|
||
Comment on attachment 9505769 [details]
Bug 1971382 - allow dropping tabs into collapsed tab groups r=dwalker,jswinarton,dao
Actually this failed to land :/
Updated•4 months ago
|
Comment 12•4 months ago
|
||
Tested as per Comment 9 on Windows 10, Ubuntu 22.04 and macOS 15 using the latest Nightly 143.0a1. No issues were found when dragging/dropping an active tab from Tabs group into a collapsed one. Marking this enhancement as Verified Fixed.
Comment 13•4 months ago
|
||
Comment on attachment 9505769 [details]
Bug 1971382 - allow dropping tabs into collapsed tab groups r=dwalker,jswinarton,dao
Unfortunately, we are in RC week, this failed to land, and we are out of betas. If you want to have this considered for a dot release, please open a rebased patch request for mozilla-release.
Updated•4 months ago
|
Updated•4 months ago
|
Description
•