Does SW already handle request to the `manifest.json`?

Yes.

acmesquares (or other interested party): does this bug still happen? Can you provide a repro?

Yes still happens.
The request for the image fires correctly, appears in the network page correctly,
however the 'App manifest' page, under 'Installability' shows the error:
"Some of the icons could not be loaded".

Thanks. Would it be possible to add a simple repro, even just copy/pasting stuff in a comment here or ideally putting something on glitch.me? I'm not familiar with app manifest syntax.

+dominickn: do you agree it makes sense for this request to go through the service worker, and is this specified or what other browsers do? The only worry I'd have is whether a service worker can trigger loading this icon, enabling it to keep itself alive indefinitely.

Where does the resource load happen today? Is it from the browser or the renderer?

Does this only happen in the Application panel of devtools? It's possible that devtools is trying to fetch the icons directly to display here. But this purpose is outside that of what the service worker cache should be used for.

More generally, the web app manifest just specifies a path to an icon (e.g. img/icon.png). If the site itself requests the icon, that should hit the SW cache if set up correctly just like any other resource request. There shouldn't be any special handling needed for icons in the manifest or outside the manifest: just cache it like you would anything else.

Chrome itself fetches manifest icons via the WebContents::DownloadImage API, and perhaps devtools has its own fetch code for icons. I don't know if that goes through the SW, but my inclination is that these requests shouldn't: it's Chrome itself making the request, not code in the website.

c#14: Is it a correct rewording to say you'd expect the service worker to get fetch events for the icon if the icon falls in the service worker's scope? (leaving aside DevTools) I think the problem here is Chrome broadly makes two types of requests that go through service workers:
1. a main resource request (usually a navigation) that makes a context (usually document) possibly controlled by a service worker, or
2. a subresource resource from that context

Requests for (1) go to the service worker of that URL's scope. Requests for (2) go to the context's controlling service worker. Are manifests fetched done with a relevant frame/document context, or can they be done without such a context? If the latter, we'd need to treat the request like (1) and lookup the SW to talk to. If the former, we can use the frame's SW.

I don't suppose this is specified behavior in the appmanifest spec?

#15: yes, I would assume that the service worker should get fetch events for the icon if the icon is within the SW scope.

Manifests are fetched wrt to the Document object of the top-level browsing context (https://www.w3.org/TR/appmanifest/#obtaining). My reading of the spec is that we can use the frame's SW. WDYT?

c#16: Thanks yes! It looks like the spec is missing setting |request|'s |client| but I assume it's an oversight rather than intentional. The |client| is how it gets to the relevant SW via:

- "Await the result of performing a fetch with request, letting response be the result." in https://www.w3.org/TR/appmanifest/#obtaining
- "perform a fetch" in https://fetch.spec.whatwg.org/#concept-fetch goes to "main fetch" then "http fetch" 
- "Set response to the result of invoking handle fetch for request. [HTML] [SW]" goes to "handle fetch" in https://w3c.github.io/ServiceWorker/#handle-fetch
- Handle Fetch sees it's a subresource request (destination is "manifest") and routes to the |client|'s active service worker.

Do you want me to a file a bug against Web App Manifest?

Looks kind of like https://github.com/w3c/manifest/issues/481

Yeah, we could probably ping that issue. :)