feat: isolate parent and child frames when handling requests #2324
Conversation
| @@ -155,6 +160,10 @@ async function handleRequest(event, requestId) { | |||
| async function resolveMainClient(event) { | |||
| const client = await self.clients.get(event.clientId) | |||
|
|
|||
| if (activeClientIds.has(event.clientId)) { | |||
kettanaito
changed the title
| @@ -41,6 +43,11 @@ export function printStartMessage(args: PrintStartMessageArgs = {}) { | |||
| console.log('Worker scope:', args.workerScope) | |||
| } | |||
|
|
|||
| if (args.client) { | |||
| // eslint-disable-next-line no-console | |||
| console.log('Client ID: %s (%s)', args.client.id, args.client.frameType) | |||
There was a problem hiding this comment.
I'm also improving the activation message to include the client ID that prompted it, as well as the client frame type (top-level/nested). This helps during debugging.
kettanaito
force-pushed
the
fix/nested-frames-with-msw
branch
from
09fad7d
to
2b1128d
Compare
kettanaito
changed the title
|
Also a good point that we still won't properly support this scenario: Since a.1.1 doesn't call I'd say the expectation here is that the Unfortunately, there's no hierarchical relationship of the service worker clients. You also cannot know the actual client ID on the client to do any sort of logic on the library's side. See w3c/ServiceWorker#1556. |
Released: v2.5.0 🎉This has been released in v2.5.0! Make sure to always update to the latest version ( Predictable release automation by @ossjs/release. |
The problem
If the page calls
worker.start()and has a child frame that also callsworker.start(), the requests from the frame will only be resolved against the top-level parent'sworkerand its handlers.The solution
During the
resolveMainFrameclient lookup, if the eventclientIdis in the active client ids of the worker, return it. Don't lookup the clients because the top-level client will always match first, ignoring any underlying otherwise matching nested client ids.