Scoped WordPress instances to support multiple browser tabs

[adamziel]

What problem does this PR solve?

Adds support for running WASM WordPress in multiple browser tabs and solves #9.

All WordPress requests are routed through a single service worker shared between all browser tabs. The request lifecycle looks as follows:

1. A request originates in a specific tab
2. A service worker intercepts it and requests the same tab to pass it to its WASM WordPress instance
3. The tab renders it and sends the response to the service worker
4. The service worker responds to the intercepted HTTP request using the WordPress-generated response
5. The original tab receives the WordPress-generated response and displays it to the user

It's a back-and-forth conversation between a specific browser tab and the service worker.

Unfortunately, Service workers communicate with tabs using a BroadcastChannel – it's a messaging strategy that routes every message to every listener. As a result, each WordPress request was rendered in every tab, often causing unexpected behaviors.

How does this PR propose to solve it?

This PR introduces a concept of WordPress scope and enables the service worker to post BroadcastChannel messages scoped to specific listeners.

Scoping a WordPress instance means installing it at a unique pathname starting with /scope:<unique number>. For example:

• In an unscoped WordPress instance, /wp-login.php would be available at http://localhost:8778/wp-login.php
• In a scoped WordPress instance, /wp-login.php would be available at http://localhost:8778/scope:96253/wp-login.php

The scope number is a random and unique number generated by a specific browser tab. The service worker is aware of this concept and will use any /scope: found in the request URL to tag all the related BroadcastChannel communication. The WASM workers running in specific browser tabs will then ignore all the BroadcastChannel communication with an unfamiliar scope attached.

Alternatives considered

• Using the scope feature of ServiceWorker – it led to multiple worker registrations and was hard to reason about.
• Loading Workers from a tab-specific unique URL, e.g. sw.js?tab_id=432 or sw-1.js – it led to the same problems as relying on the scope feature.
• Match the request with its originating tab in the ServiceWorker – There's not enough information available. The worker can't figure out the top-level client ID from a request originating in an iframe, and the top-level client wouldn't be able to tell whether the request originated in its browsing context.
• Scoping WordPress instance by a domain, e.g. w87953.localhost – it would require setting up a catch-all DNS domain to even use this project. That's a steep barrier of entry.
• Displaying an error in other browser tabs – it would be a large and unnecessary limitation.

How to test?

Run npm run dev and open the WASM WordPress page in a few different browser tabs. Log in, create pages, play with it, and confirm that each tab behaves as expected. Specifically:

• No tab should unexpectedly log you in or out
• No pages and changes should leak between the browser tabs

Follow-up work

• If a use-case arises, a tab could use sessionStorage to preserve the scope across page reloads.