Proposal: Tab Knowledge API -- gaining knowledge about same-origin tabs

[vmpstr]

What problem are you trying to solve?

Hoping to improve the ergonomics of web sites accessing information about tabs opened to the same origin. Additionally allowing some minimal control (focus specifically) to be able to switch to those tabs. See https://github.com/vmpstr/web-proposals/blob/main/explainers/tab-knowledge.md

What solutions exist today?

I believe partial knowledge is available by using shared workers. These workers can track the new tabs creation and deletion and update internal tracking.

How would you solve it?

A new API that can directly provide new information. More information in the explainer

Anything else?

I'm looking for early feedback to see if this is a direction that implementors are interested in exploring.

[tabatkins]

A shared worker grants full knowledge, no? Any of the tabs can share everything they know with others in their origin group. This is just making that communication more ergonomic.

(Plus tab-switching, of course.)

[vmpstr]

It has full knowledge of when new contents are opened. But there was some question if a page can reliably know whether the tab was closed. @tdresser had some exploration on the topic. Regardless of the answer though, it may be possibly to have this full knowledge, yeah

[tdresser]

Assuming we ship the MessagePort onclosed event, then a shared worker grants full knowledge, except for knowing tab order and tab group ID (currently excluded from the explainer, but I think these could be safely added).

[Kaiido]

I don't think we necessarily need the closed event. We can already achieve this with Web Locks today: https://basic-tab-knowledge-with-locks.glitch.me/

However there are a couple of points that differ from the proposed API in the explainer:

• SharedWorker (and BroadcastChannels for that matter) are opt-in, in the sense each client has to request access to it. So should this API also be opt-in? Should it also take a "name" to be able to create multiple groups from the same origin?
• SharedWorker do not look only at top browsing contexts, i.e. a framed document would still be seen by it. From the use-case it's not clear if that would be a good thing or not.

Also, I wonder if there could be a mean to distinguish which entry we are (doing the id on url or title is not enough).
And I suppose there will be requests to have a communication channel between those entries, might be good to think of it right now.

[tdresser]

Nice solution!

I think we'd want to only include top level browsing contexts.
FWIW, I don't think requiring an opt-in is necessary. Curious on @vmpstr's take though.

Clarifying which entry we are makes sense to me.

I don't think we're aware of any use-cases which require communication between entries.
Do you have an example concrete use-case?

[vmpstr]

I agree with @tdresser that I didn't think an opt-in would be necessary here.

However, I think there's something to be said for incognito modes or different profiles or something like that, where it's unclear whether we should be providing the information to the page across those user defined boundaries. I'm not sure what the right spec term for this is though.

[smaug----]

BroadcastChannel was designed for this use case. Why is that not enough?
One can register to a certain channel when loading the page (and send a message to other participants) and send unregister message when pagehide is fired.

[tdresser]

pagehide is frequently never fired (e.g., tab crash, or fast tab shutdown).

This proposal also enables a page to focus an existing tab, and provides a surface for (in the future) exposing tab order, or tab group ID.

[Kaiido]

Do you have an example concrete use-case?

No "concrete" use-case, but that sounds like a natural extension to this feature. I guess that could be useful if you want to sync states between tabs. Of course this could also be achieved through a BroadcastChannel, but that looks more cluttered to have to set that up.

BroadcastChannel was designed for this use case.

BroadcastChannel isn't really good at telling which pages are active though. While the pagehide issue could also be solved by the use of Web Locks, it's also very difficult to set up initially: you need to do a first round asking if you're alone, and you need to hope you'll get an answer in a timely manner to set up the counts otherwise you may have conflicting reports.
In this regard, a ServiceWorker is way better, since this gives a single source of truth. But it's not that easy to set up as this requires having an external script all pages can access.

[mkruisselbrink]

Is the proposed API different from the existing Clients API (and should it be)? I know that API is currently limited to just service workers, but I don't think there were any real concerns around exposing it more widely (w3c/ServiceWorker#955), it mostly just stalled because there wasn't enough interest from browsers and site developers to spent the resources on. And if there is other functionality missing from that API it might make more sense to extend the API rather than invent an entirely new API?

[vmpstr]

TIL about Clients API. That's almost exactly what this proposal aims to accomplish! We should possibly revive the effort to expose this outside of service workers, since that would make adoption easier. It wasn't clear to me what you mean by

there wasn't enough interest from browser and site developers to spent the resource on.

Specifically, you mean the site developers would not want this exposed outside of service workers because it would somehow become burdensome to use? Or something else?

One additional feature of the proposed API is the ability to switch tabs when focused. I see the WindowClient interface has focus() as well, but that doesn't seem to include the ability to actually switch a tab -- at least not that I see.

Would it make sense to propose adding such functionality to the Clients API?

Also, there may be future enhancement like exposing more information about the client, but that certainly can go into the Client interface as well.

[mkruisselbrink]

Specifically, you mean the site developers would not want this exposed outside of service workers because it would somehow become burdensome to use? Or something else?

No, I meant more that work on this wasn't prioritized at the time because site developers weren't asking for it (but that might also be because they weren't aware of it).