Change placement of tabs when removing tabs from a tab group
Categories
(Firefox :: Tabbed Browser, enhancement)
Tracking
()
People
(Reporter: sthompson, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [fidefe-tabgrps-tabbrowser] [UX-tabgrps-review])
Copying from https://bugzilla.mozilla.org/show_bug.cgi?id=1932489#c1
Removing the first tab from a group shouldn't move that tab to the end of the group instead it should attach the group label to the next tab.
ungroupTab(tab) { if (!tab.group) { return; } this._handleTabMove(tab, () => gBrowser.tabContainer.insertBefore(tab, tab.group.nextElementSibling) ); }
add check here if the tab is the first in the group and not the last tab or single tab use
gBrowser.tabContainer.insertBefore(tab, tab.group.previousElementSibling.nextElementSibling)
Updated•9 months ago
|
Reporter | ||
Updated•9 months ago
|
Reporter | ||
Comment 1•9 months ago
|
||
@Amy Regarding the behavior of the "Remove from Group" context menu option when right-clicking on a tab inside of a tab group.
Current behavior:
Always moves the tab(s) to be just after the tab group that the tab was in (to the right for LTR, to the left for RTL)
Behavior recommended @tabmix.onemen:
The first tab of the tab group should move just before the tab group that the tab was in, but all other tabs should follow the current behavior.
One other option that came to mind was to ungroup tabs to the closest edge, so that in a tab group with 9 tabs, removing tabs 1 through 4 would place them before the tab group, while removing tabs 5 through 9 would be placed after the tab group.
Any ideas? What do you think about priority?
Comment 2•9 months ago
|
||
we want it to be as intuitive as possible
I don't think that placing tabs in both edges is good, consider the case when user remove multiple tabs from a group, if some moves before the group and some after the group the result can be confusing
My suggestion is to place tab(s) that was removed from the group based on the drag direction when user dragged tab(s) out of the group, or after the group when the action was not triggered by drag event.
Comment 3•8 months ago
|
||
I think the last suggestion would cause tabs to also move in both directions if a user multi-selects tabs and clicks "remove" if the user dragged these tabs from both directions into the group.
My recommendation would be to move tabs to the closest edge as you stated "so that in a tab group with 9 tabs, removing tabs 1 through 4 would place them before the tab group, while removing tabs 5 through 9 would be placed after the tab group"
If the user has several tabs selected (ie tab 1 and the last tab) we move the group of tabs based on the active selected tab. If tab 1 is the active tab then we move tab 1 and last tab to the left of the group to avoid long scrolling.
Logic being that we avoid having to scroll to the end of the tab group if the user has a tab group that extends past viewable tab strip. It can be jarring if tab 1 has to be moved to the end of the tab group and the tab strip has to scroll to the end position.
Description
•