javascript - Persistent unique ID for Chrome tabs that lasts between browser sessions

Question

I'm trying to ascertain some way to establish a unique ID for Chrome tabs that meets the following conditions:

• Uniquely identifies each tab
• Stays the same for a given tab between browser restarts (session-restored tabs)
• Stays the same if a tab is closed and then reopened with Undo Closed Tab (Ctrl+Shift+T)
• Stays distinct if a tab is duplicated

I've done some rather aggressive research to find a comprehensive solution, but nothing seems to quite do the trick. Here are the methods I have tried, in increasing order of efficacy:

• Use Chrome's provided tab.id: does not persist between browser sessions or close/undo-close
• Put a GUID in cookies: is not unique per tab, only per domain/URL
• Put a GUID in localStorage: persists between browser sessions and close/undo-close, but is not unique per tab, only per domain
• Put a GUID in sessionStorage: unique per tab, persists across close/undo-close, unique for duplicated tabs, but is wiped out between browser sessions
• Use identifiable webpage document attributes as a unique key: this is the best approach I've found so far. A key can be constructed via a content script from the following values: [location.href, document.referrer, history.length].

Regarding this last approach, the constructed key is unique across all tabs which share a common URL, referrer, and history length. Those values will remain the same for a given tab between browser restarts/session-restores and close/undo-closes. While this key is "pretty" unique, there are cases where it is ambiguous: for example, 3 new tabs opened to http://www.google.com would all have the same key in common (and this kind of thing happens pretty often in practice).

The "put GUID in sessionStorage" method can additionally be used to disambiguate between multiple tabs with the same constructed key for the close/undo-close and duplicated-tab cases during the current browser session. But this does not solve the ambiguity problem between browser restarts.

This last ambiguity can be partially mitigated during session restore by observing which tabs Chrome opens together in which windows, and extrapolating for a given ambiguous key which tab belongs to which window based on the presence of expected 'sibling' tabs (recorded during the previous browser session). As you might imagine, implementing this solution is quite involved and rather dodgy. And it can only disambiguate between same-keyed tabs that Chrome restores into different windows. That leaves same-keyed tabs that restore into the same window as irreconcilably ambiguous.

Is there a better way? A guaranteed unique, browser-generated, per-tab GUID that persists between browser restarts (session restores) and close/undo-close would be ideal but so far I haven't found anything like this.

Answer 1

The question here does most of the discovery work, and the accepted answer basically completes it, but there's a big implementation gap still for people looking to implement something which requires persistent tab IDs. I've attempted to distill this into an actual implementation.

To recap: Tabs can be (almost) uniquely and consistently identified as required by the question by maintaining a register of tabs which stores the following combination of variables in local persistent storage:

• Tab.id
• Tab.index
• A 'fingerprint' of the document open in the tab - [location.href, document.referrer, history.length]

These variables can be tracked and stored in the registry using listeners on a combination of the following events:

• onUpdated
• onCreated
• onMoved
• onDetached
• onAttached
• onRemoved
• onReplaced

There are still ways to fool this method, but in practice they are probably pretty rare - mostly edge cases.

Since it looks like I'm not the only one who has needed to solve this problem, I built my implementation as a library with the intention that it could be used in any Chrome extension. It's MIT licensed and available on GitHub for forking and pull requests (in fact, any feedback would be welcome - there are definitely possible improvements).