Consider preserving split view when moving them at once with tabs.move()
Categories
(WebExtensions :: Frontend, enhancement)
Tracking
(Not tracked)
People
(Reporter: robwu, Unassigned)
References
(Blocks 1 open bug)
Details
When the tabs.move() API receives multiple tabs, it is similar to selecting multiple tabs and moving them at once.
When the user does that through browser UI, split views are preserved.
When the tabs.move() extension API is used, split views are lost. This is because its implementation moves tabs sequentially instead of in bulk, and when a tab departs a split view, the split view disappears.
Chrome's implementation behaves similarly in this regards.
Since Firefox's tries hard to maintain the unity of a split view, we should consider whether we want to change the implementation to preserve split views where possible, possibly by relying more on the tabbrowser implementation. Making such changes may also affect tab groups.
Currently, we do not have an extension API to explicitly break a split view, so perhaps we should only consider changing this once we have an explicit API to split a split view. We should also try to make sure that the behavior is consistent across the extension API, e.g. either try to consistently preserve the split or unsplit where applicable (e.g. see bug 2016751).
|
Reporter | |
Comment 1•3 months ago
|
||
My understanding of the behavior predated the changes from bug 2004383.
Although the implementation requests to move tabs sequentially, the implementation moves the whole split view at once at the tabbrowser level.
I will close this bug. Test coverage for the scenario will be added in bug 2016754.
This write-up here should be helpful for documentation purposes (dev-doc-needed).
Description
•