Consider returning the tabs of split views even when the other tab of the split view was not passed to `tabs.move`
Categories
(WebExtensions :: Frontend, enhancement)
Tracking
(Not tracked)
People
(Reporter: robwu, Unassigned)
References
(Blocks 1 open bug)
Details
The tabs.move() method returns an array, reflecting the tabs that have moved. Currently, this array only contains tabs for the tabIds that the extension explicitly passed to tabs.move(). Tabs may be missing, e.g. if the extension passed pinned tabs and tried to move between non-pinned tabs.
When a tab in a split view is moved, the whole tab split is moved, even if the extension did not specify the other tab ID. On the API design, we have two options:
- (current) only return the tabs that were specified explicitly.
- (alternative option) also return tabs that were part of a tab split.
A downside to the alternative option is that extensions may receive unexpected tabs in tabs.move().
In any case, extensions can already witness tab movements through the tabs.onMoved events (and tabs.onAttached and tabs.onDetached for cross-window moves, especially when bug 2017148 is fixed).
The purpose of this bug is to consciously evaluate the design, patch the implementation as needed, and document the outcome on MDN.
|
Reporter | |
Updated•2 months ago
|
|
|
Reporter | |
Comment 1•2 months ago
|
||
I discussed this with Luca. We both agreed that it would be riskier to include tabs that were not requested, than to not do so.
As written in the report, extensions interested in tracking the tab positions can already use the tabs.onMoved events (and tabs.onAttached and tabs.onDetached for cross-window moves), or even using tabs.query.
Description
•