Proposal: Tab Knowledge API -- gaining knowledge about same-origin tabs about html HOT 9 OPEN

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.

from html.

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.)

from html.

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

from html.

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).

from html.

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?

from html.

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.

from html.

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.

from html.

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.

from html.

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.

from html.