Open
Bug 1967937
Opened 1 year ago
Updated 1 year ago
Unify tab/tab group adoption logic when adopting tab groups in a new window
Categories
(Firefox :: Tabbed Browser, task, P3)
Firefox
Tabbed Browser
Tracking
()
NEW
People
(Reporter: robwu, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [fidefe-tabgrps-tabbrowser])
While looking at tab group adoption logic in bug 1965343, I noticed that there are two potential points of improvements, that all come together in the swapBrowsers handler at onLoad in browser-init.js:
- When adopting a tab group via drag and drop, a tab group label element is passed to the window. Its tab group would make more sense, and allow for deduplication of code (bug 1965343 adds another way to adopt a tab group into a new window). In bug 1965343 I also added logic to make the originally selected tab the selected tab after adopting a tab group in a new window, I think that it also makes sense to have that for drag & dropped tabs.
- The regular tab adoption flow consists of setting up a tab in
_setupInitialBrowserAndTab()and then swapping the browsers. The tab group adoption logic works by creating a new window (with a default blank tab), moving all tabs in the group from the old window to the new window, grouping the tabs again and then removing the default blank tab from the new window.- If we set up the default blank tab in
_setupInitialBrowserAndTabbased on a tab from the tab group, then we could reuse it to avoid creating and closing an extra tab.
- If we set up the default blank tab in
Updated•1 year ago
|
Blocks: 1907099
Severity: -- → N/A
Points: --- → 1
Priority: -- → P3
Whiteboard: [fidefe-tabgrps-tabbrowser]
Updated•1 year ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•