I'm getting OOM in heap setup when I open https://editor.construct.net/

If root-sw.js refers to the editor.construct.net/ scope, why do you expect sw.js to be around? The page is under the control of only one SW, in this case it would be root-sw.js

The page explicitly registers two Service Workers at different scopes. You can see it doing this in the console, each one logs a message.

That's fine, but we only inspect the one in control of the page inside page inspector. If you want unrelated sws, find them under Application -> Service Workers -> All

Oh right, I didn't know you had to go there. But if I try to inspect sw.js from there, the first time I click sw.js it just opens the source in plaintext in a new browser tab. For some reason that appears to kick it in to life, and if I try again it opens in the sources tab. But still, if I add a breakpoint to the fetch handler, it never breaks.

> But still, if I add a breakpoint to the fetch handler, it never breaks.

I assume you open another page under /r70-2/ to trigger fetch, right?

No, we rely on the fact that the Service Worker with the longest scope matching the URL intercepts the request, as described in the "Match Service Worker Registration" algorithm, step 5: https://w3c.github.io/ServiceWorker/#match-service-worker-registration

Only one service worker will control the page. It is matched against the page url and scope matters there, but it only matters for the main resource and not its subresources.

But the "Handle fetch" algorithm steps include "Match Service Worker Registration", so it appears a fetch for a subresource within the scope of another SW will cause that SW to handle the fetch. We observe this in production, since the second SW is the one that caches files for offline use, but our web app still works offline when we visit the root URL (which basically just caches the root HTML page). So given that other SWs can handle fetches, shouldn't it be possible to add breakpoints on them?

As I said, there is only one service worker that controls the page at a time. For https://editor.construct.net/, this is going to be root-sw.js. It will get all the fetch requests for all the subresources, including for everything under https://editor.construct.net/r70-2/*.

However, when you navigate to a frame under r70-2, such as https://editor.construct.net/r70-2/main.html, sw.js will be the service worker in control and it will handle all the fetches. That's what you should observe in production.

> the "Handle fetch" algorithm steps include "Match Service Worker Registration",

We looked into this and it appears this only happens in the case of "the request is a non-subresource request". A non-subresource request is one of these: ` "document", "report", "serviceworker", "sharedworker", or "worker"`

Well, as usual, I'm baffled by how Service Workers work! I tried to get to the bottom of this and came up with this test:

1. Visit https://www.scirra.com/labs/nested-sw-test/
2. Open dev tools, observe SWs register and cache
3. Reload so SWs are activated
4. Click 'Fetch v1-data.json'
5. Observe the console logs that the root SW handled the fetch, did not find it in its cache, so went to network
6. In dev tools, check "offline mode" and "disable cache"
7. Click 'Fetch v1-data.json' again
8. Observe that again, the root SW handles the fetch, does not find it in its cache, and sends it to network

Expected result:
We're offline, cache is disabled, and a request was sent to network - so it should fail

Observed result:
The request completes successfully. Dev tools' network panel indicates 'v1-data.json' was handled by root-sw.js and returned "from disk cache". However, v1-data.json is neither available over the network, nor present in cache. The only place it could have come from is the cache named "v1". You can verify in the Application tab of dev tools that v1-data.json is only present in the "v1" cache, which root-sw.js does not attempt to look in.

This led me to believe that the request was handled by v1-sw.js and looked up in the "v1" cache, which is also what led me to set a breakpoint in v1-sw.js. Allowing the v1-sw.js to handle the fetch seems like a logical and useful thing to do and covers this use case nicely, but... it doesn't? Then what's going on?

Our production app has relied on this approach for offline support since March, and it appears to have been working all that time, so... now I have no idea how our offline support is actually working!