[Spike] Investigate and document "one window, one tab" pattern in Android and see if "one window, many tabs" is worth pursuing
Categories
(GeckoView :: General, task, P3)
Tracking
(Not tracked)
People
(Reporter: olivia, Unassigned)
References
Details
(Whiteboard: [gv-perspective-work][gv-h1-2025?][fxdroid][geckoview][gv-grab-bag])
Right now, GeckoView uses a new Gecko browser window for every GeckoSession. This means every Android Gecko window has exactly one Gecko tab. In contrast to the Desktop patteren where one Gecko window may have many tabs. Each UI tab in Fenix is one GeckoSession, which means it has one Gecko window, one Gecko tab for each conceptual Fenix UI tab.
For this bug:
- It would be good to documument the current behavior, underlying architecture decisions, and generally document how this works on Android.
- Determine if a "one window, many tabs" patteren on Android could be worth pursuing for performance reasons.
- Additionally, if it seems feasible or worthwhile, file a follow-up bug to create a prototype of a "one window, many tabs" patteren in GeckovView to see if there are any performance wins. (Would require something like a
GeckoSessionStackto manage this.)
One reason for the original architectural patteren might be:
With WebView, you can have multiple WebViews visible at once, so we needed a system to have multiple different windows visible which can be laid out by the android layout system.
So in order to do that, each of those are separate toplevel windows for each GeckoSession.
(from :nika and :jonalmeida)
Comment 1•9 months ago
•
|
||
Bug 1584252 comment 9 suggests that implementing the Web Extensions API tabs.move is blocked on the current "one window, one tab" design.
Updated•9 months ago
|
Updated•9 months ago
|
Updated•9 months ago
|
Updated•9 months ago
|
| Reporter | ||
Updated•3 months ago
|
Updated•3 months ago
|
Description
•