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)

task
Points:
1

Tracking

()

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 _setupInitialBrowserAndTab based on a tab from the tab group, then we could reuse it to avoid creating and closing an extra tab.
Blocks: 1907099
Severity: -- → N/A
Points: --- → 1
Priority: -- → P3
Whiteboard: [fidefe-tabgrps-tabbrowser]
You need to log in before you can comment on or make changes to this bug.