1993037 - Expose splitViewId in tabs extension API

Status: RESOLVED FIXED

(WebExtensions :: Frontend, enhancement, P2)

Description

[Rob Wu [:robwu]]

Add splitViewId to tabs.Tab and tabs.onUpdated.

API proposal: https://github.com/w3c/webextensions/pull/842

If anyone is interested in working on this, there is an example of the extension API specific bits in the patch related to groupId (bug 1959713 and bug 1959716). The internals of splitViewId are in bug 1984652.

Comment 1

[YUKI "Piro" Hiroshi]

This is just an opinion: it looks natural if APIs about the split view feature are designed similar to tab groups, to reduce confusion.

• Created new split view: notified to listeners of browser.splitView.onCreated
• Changed existing split view: notified to listeners of browser.splitView.onUpdated
  • When a tab is added to an existing split view, or removed from an existing split view, it will be notified via browser.tabs.onUpdated.
• Unsplitted existing split view: notified to listeners of browser.splitView.onRemoved

However, it looks little hard to design a new method to create new split view.

• Idea 1: strategy same to tab groups - creating a new tab by browser.tabs.create() and bundle it to another tab via browser.splitView.create({ tabIds: [ID of tabs] }) or browser.tabs.split({ tabIds: [ID of tabs] })
  • Pros: less confusion.
  • Cons: Not atomic.
• Idea 2: atomic method to create a new split view and a new tab with single API call, like browser.tabs.split({ tabId: ID }) which returns an object containing both information about the newly opened tab (tabs.Tab) and the new split view. Or it possibly return just a tabs.Tab with splitViewId.
  • Pros: Atomic and safe.
  • Cons: It may require more discussion about its API design to construct a consensus.

I think the idea 2 (atomic API) looks better for safety and easility for addon development.

Comment 2

[Rob Wu [:robwu]]

Thanks for your input Piro! For better visibility to others, the Tree Style Tabs issue tracking Split View support is at https://github.com/piroor/treestyletab/issues/3806 where I asked for feedback on necessities of the API beyond splitViewId as specified at https://github.com/w3c/webextensions/blob/main/proposals/split_tabs_proposal.md

The current proposal already provides read-only insights in the split view concept, but lacks a way to create split views, and it is also not possible to read or modify additional configuration (e.g. horizontal vs vertical splits). The question that I have is whether the proposed API is good enough for awareness of split views (and e.g. not inadvertently take tabs out or in of split views).

Beyond that the question is whether there is a need for additional functionality (whether part of the same release as the initial split view feature, or potentially in a later browser release). Unless it's fairly simple, the outcome if any would be implemented in a separate Bugzilla ticket.

And when reading my response below, keep in mind that this is intended as an open discussion on the API shape; I am still exploring the space and possibilities, so my reply below is me thinking out aloud, aiming to collect relevant API requirements and constraints.

This is just an opinion: it looks natural if APIs about the split view feature are designed similar to tab groups, to reduce confusion.
( summary: splitView.onCreated, onUpdated, onRemoved )

The tabGroups API does not provide any information in tab membership; that part is handled by tabs.onUpdated (and tabs.group() + tabs.ungroup() + tabs.query()). In the context of split views, what the dedicated events can offer is a way to observe the start and end of a (split view) identifier's existence. The question is whether that fills a true need; what is the use case?

The only event in the current API proposal is an addition to the existing tabs.onUpdated event. The benefit here is simplicity in being notified of relevant changes to the state of individual tabs, but a potential weakness is the inability to be notified at once for multiple tabs.

The choice of tabs.onUpdated for detecting split view changes implies that it is not possible to be bulk-notified of split view changes across multiple tabs in a single event, nor is it possible to know exactly which split view changed (without the extension keeping track of the relevant splits, because all that an extension sees would be tabs.onUpdated with splitViewId -1). But even if an extension were to lose track of the actual split views, then they can use tabs.query() to get the most current view of split views (including other relevant information such as which tab is active and whether it is in a split view).

However, it looks little hard to design a new method to create new split view.

Before I comment on your proposed ideas, I'd like to be explicit on my understanding of the split views' characteristics:

• split tabs are always adjacent to each other.
• a split contains two tabs (but I can envision a future where there may be more, e.g. in a grid view).
• when two tabs in a split become separated (e.g. tab moves or gets closed), the split disappears and each tab is just a regular tab. Presumably the disappearance of the split view also results in the invalidation of splitViewId (unless it is possible for a split view to exist with one tab - this is an open question for Sarah).

While a split view with one tab doesn't sound tremendously useful, they can conceptually exist from the extension's point of view with the current API design: if they monitor tab changes with tabs.onUpdated, they see one tab change at a time and may therefore (temporarily) have the understanding of a tab split consists of one tab only.

Idea 1: strategy same to tab groups - creating a new tab by browser.tabs.create() and bundle it to another tab via [a method taking a list of tabIds]
Idea 2: atomic method to create a new split view and a new tab with single API call
I think the idea 2 (atomic API) looks better for safety and easility for addon development.

The tabs.group() method (idea 1) has too much functionality in my opinion. Besides tabGroups membership, it can also move tabs around. If we were to introduce a method to change ownership, then I'd like it to do the bare minimum (changing split view membership, throwing an error if requirements are unmet) and letting existing methods (tabs.move()) take care of the actual movements.

Idea 2 is about creating a new tab that is part of an existing split. Rather than a new method to create a tab, I would be more in favor of extending the existing tabs.create() method with an option to take an existing splitViewId (if a splitViewId with a single tab can exist).

Comment 3

[YUKI "Piro" Hiroshi]

Oh, I intentionally put some ideas out from the table because I thought that there is a strategy about WebExtensions API design: they need to be minimal. It looks better that browser.splitView.onCreated/onUpdated listeners receive an object containing (new/added/removed) member tabs information, like around browser.tabs.onHighlighted.

Idea 2 is about creating a new tab that is part of an existing split. Rather than a new method to create a tab, I would be more in favor of extending the existing tabs.create() method with an option to take an existing splitViewId (if a splitViewId with a single tab can exist).

I agree this idea if it is possible. So for example, when we create a split view with the contents duplicated from the active tab:

const tab = (await browser.tabs.query({ active: true }))[0];
const splitView = await browser.splitViews.create({ tabId: tab.id, orient: browser.splitViews.VERTICAL /* this is just an idea */ });
const tabOfSplitView = await browser.tabs.create({ tabId: tab.id, splitViewId: splitView.id });

Comment 4

[Sarah Clements [:sclements]]

Hi Piro, we don't have a concept of orientation for splitview, ie vertical vs horizontal; the tabstrip is ultimately the same and just moves location, with the tabs remaining consistent across orientations. Can you explain a bit more why you'd want this/what it'd be needed for?

Comment 5

[YUKI "Piro" Hiroshi]

(In reply to Sarah Clements [:sclements] from comment #4)

Hi Piro, we don't have a concept of orientation for splitview, ie vertical vs horizontal; the tabstrip is ultimately the same and just moves location, with the tabs remaining consistent across orientations. Can you explain a bit more why you'd want this/what it'd be needed for?

Sorry my less description. It is just an example to describe how the method accept parameters to create a new split view, and it doesn't mean that I really want the orientation feature.

Comment 6

[Rob Wu [:robwu]]

Attachment: Bug 1993037 - Add splitViewId to tabs extension API

This adds the following extension API features:

• tabs.Tab.splitViewId
• tabs.SPLIT_VIEW_ID_NONE
• tabs.onUpdated event's changeInfo.splitViewId and "splitViewId"
  filter (desktop only, not on Android).
• tabs.query method to accept splitViewId option.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/6a49efa7ac28
https://hg.mozilla.org/integration/autoland/rev/dfdf74d045c3
Add splitViewId to tabs extension API r=rpl,tabbrowser-reviewers,sthompson

Comment 8

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/dfdf74d045c3

Comment 9

[Rob Wu [:robwu]]

dev-doc-needed: to document the new splitViewId property.

This splitViewId property aligns with the release of the split view feature (bug 2012704).
This impacts the behavior of extension APIs, notably tabs.move. Please see bugs linked to the extension API meta (bug 2016749) for more information on the behaviors.

This bug only adds the ability to observe the existence of split views. The creation and unsplitting of split views is not yet possible, and that follow-up is tracked in bug 2016928. API design input continues to be welcome, I'll try to align with other browsers in the WECG.