Make changes to moveTabTo and handleTabMove callbacks to account for tabs in a splitview
Categories
(Firefox :: Tabbed Browser: Split View, defect, P1)
Tracking
()
People
(Reporter: sclements, Assigned: sclements)
References
(Blocks 1 open bug, Regressed 1 open bug)
Details
(Whiteboard: [fidefe-splitview])
Attachments
(1 file)
There's a few cases I misssed when working on bug 1998199, mostly seem to be with the various callbacks in #handleTabMove in tabbrowser.js, where its not checking for whether a tab is within a splitview. This is pretty noticeable in cases like moveTabTo when an elementIndex is not passed in, as is the case with sidebar extensions like TST but likely in other scenarios.
This patch also covers moveTabForward and moveTabBackwards used by keyboard shortcuts; it handles both the movement of tabs within splitviews (discussed with Yulia that we should keep those tabs together and move the entire wrapper) and prevents tabs from being moved into a splitview.
Updated•3 months ago
|
| Assignee | ||
Updated•3 months ago
|
| Assignee | ||
Updated•3 months ago
|
| Assignee | ||
Comment 1•3 months ago
|
||
Updated•2 months ago
|
Updated•2 months ago
|
| Assignee | ||
Updated•2 months ago
|
Comment 6•2 months ago
|
||
Hello Sarah! I have verified the following with Firefox 149.0a1 (2026-01-14) on Windows 11, macOS 26 and Ubuntu 24:
- moving Split Views using
Ctrl+Shift+Page Upkeyboard shortcut is correclty performed - moving normal tabs before and after Split Views using
Ctrl+Shift+Page Upkeyboard shortcut is correctly performed - bug 2007738 is no longer reproducible
I have also verified Move to : Start/End/ New window context menu options, and I am hitting bug 2010201 and bug 2010203.
Can you please confirm if the above verification is enough or if there's something else I should look for? Thank you!
| Assignee | ||
Comment 7•2 months ago
•
|
||
(In reply to Alexandru Trif, Desktop Test Engineering [:atrif] from comment #6)
Hello Sarah! I have verified the following with Firefox 149.0a1 (2026-01-14) on Windows 11, macOS 26 and Ubuntu 24:
- moving Split Views using
Ctrl+Shift+Page Upkeyboard shortcut is correclty performed- moving normal tabs before and after Split Views using
Ctrl+Shift+Page Upkeyboard shortcut is correctly performed- bug 2007738 is no longer reproducible
I have also verified
Move to : Start/End/ New windowcontext menu options, and I am hitting bug 2010201 and bug 2010203.
Can you please confirm if the above verification is enough or if there's something else I should look for? Thank you!
Thanks Alexandru, if you could install the TST extension and check that a tab isn't being incorrectly moved by the extension into a splitview that'd be appreciated.
I'll handle those other bugs separately.
Comment 8•2 months ago
•
|
||
(In reply to Sarah Clements [:sclements] from comment #7)
(In reply to Alexandru Trif, Desktop Test Engineering [:atrif] from comment #6)
Hello Sarah! I have verified the following with Firefox 149.0a1 (2026-01-14) on Windows 11, macOS 26 and Ubuntu 24:
- moving Split Views using
Ctrl+Shift+Page Upkeyboard shortcut is correclty performed- moving normal tabs before and after Split Views using
Ctrl+Shift+Page Upkeyboard shortcut is correctly performed- bug 2007738 is no longer reproducible
I have also verified
Move to : Start/End/ New windowcontext menu options, and I am hitting bug 2010201 and bug 2010203.
Can you please confirm if the above verification is enough or if there's something else I should look for? Thank you!Thanks Alexandru, if you could install the TST extension and check that a tab isn't being incorrectly moved by the extension into a splitview that'd be appreciated.
I'll handle those other bugs separately.
Sure thing! I can confirm that I cannot move a tab into a Split View with TST and Sideberry extensions in the Firefox tab bar with Firefox 149.0a1 (2026-01-15) on Windows 11, macOS 14 and Ubuntu 24. However, I’ve noticed two potential issues when using these extensions, and I’m not sure whether they should be reported:
- When using the Sideberry extension, moving a tab into a Split View will show the moved tab between the Split Views, and in the tab bar, it is displayed in another place
- When using the TST extension, moving a tab into a Split View briefly shows the tab being placed in the Firefox sidebar before the Split View, after which it is moved after the Split View.
I have attached a screen recording for both scenarios here. I am closing this issue based on the comments above and because tabs cannot be moved into Split View when using the TST and Sideberry extensions. Thank you!
| Assignee | ||
Comment 9•1 month ago
•
|
||
Thanks atrif, it looks like the extension is able to organize the tabs who it wants which I think is okay. Rob, what do you think about atrifs recent comment and video? I think once you add the splitview support for extensions the can be moved together if extensions want to?
Comment 10•1 month ago
|
||
(In reply to Alexandru Trif, Desktop Test Engineering [:atrif] from comment #8)
Sure thing! I can confirm that I cannot move a tab into a Split View with TST and Sideberry extensions in the Firefox tab bar with Firefox 149.0a1 (2026-01-15) on Windows 11, macOS 14 and Ubuntu 24. However, I’ve noticed two potential issues when using these extensions, and I’m not sure whether they should be reported:
- When using the Sideberry extension, moving a tab into a Split View will show the moved tab between the Split Views, and in the tab bar, it is displayed in another place
Filed as Bug 2016751 - tabs.move() does not move a tab to the specified index when the destination is part of a split view
- When using the TST extension, moving a tab into a Split View briefly shows the tab being placed in the Firefox sidebar before the Split View, after which it is moved after the Split View.
I haven't looked closely at the extension's source, but suspect that this may be the result of attempting to move it to the right destination. Attempting to move a tab inside a split view causes it to appear at the left or right of the split, anything but the middle. The position being off by one is the subject of bug 2016751.
Description
•