Does icon validity check trigger a SW's fetch handler?

[jeffposnick]

This might be less of a bug against the spec and more of an implementation detail related to Chrome 80's current behavior.

registration.index.add() currently rejects if you pass in an icons[].src value that isn't a valid URL. I'm curious about how this determination is made, as it's making it difficult for me to accomplish something while trying out the Content Indexing API. (Sample code.)

I've got a PWA that handles incoming media sharing requests using the Web Share Target API on Android.

If a user shares an image to my PWA, that image gets saved locally using the Cache Storage API with a cache key URL that doesn't exist on a remote server—requests for that URL will only succeed if intercepted by my service worker's fetch event handler, which will bypass the network and return the cached media resource.

I am calling registration.index.add() inside of the same fetch handler that is responsible for handling the incoming POST request from the Web Share Target API. If I pass in an icons[].src value corresponding to a generic icon URL that exists on the remote server, everything works as expected. However, if I pass in a icons[].src value that refers to the newly-cached image (which, again, is only valid when intercepted by the service worker, and doesn't exist on the remote server), the add() call rejects due to an invalid icon.

I can probably refactor things so that the call to registration.index.add() happens outside of a fetch handler, if that's what's causing the failure. But my bigger question is whether the validity checks for icons is supposed to trigger a service worker's fetch handler at all—because if it doesn't, I've got a bigger issue to solve.

[rayankans]

registration.index.add() currently rejects if you pass in an icons[].src value that isn't a valid URL

What's an invalid URL in this case? I can't see the sample code, and any string would be resolved with the SW's origin.

However, if I pass in a icons[].src value that refers to the newly-cached image (which, again, is only valid when intercepted by the service worker, and doesn't exist on the remote server), the add() call rejects due to an invalid icon.

Fetching the icon doesn't bypass the service worker (it's implied in the spec by not explicitly mentioning the SW should be skipped, and the same goes for the chromium implementation).

So you are calling index.add from within the fetch handler? Grabbing the icon will also call the fetch handler. There might be some weirdness happening there. This might be easier to diagnose if you share a snippet.

[jeffposnick]

Okay, it's good to know that the SW's fetch event handler is supposed to be triggered when checking icon validity.

You can reproduce the failure by adding https://5de91c72daa70d9982fb68e9--stoic-kepler-c046f7.netlify.com/ to your homescreen and sharing an image from another Android app to it. That will trigger the fetch handler for the POST that caches the image and attempts to use the image that was just cached as the thumbnail. (Unfortunately, I don't know the image size, so '192x192' is hardcoded—is that a problem as well?)

The underlying service worker is https://5de91c72daa70d9982fb68e9--stoic-kepler-c046f7.netlify.com/service-worker.js, and I turned off some minification to help make it clearer.

When you attach DevTools from a desktop Chrome instance and inspect, you'll see a failure along the lines of

That shows the icon request not hitting the fetch handler and instead doing to the backend server, which correctly returns a 404. I have a feeling that calling index.add() from within another invocation of a fetch handler is the problem. If that's the case, I'll refactor my code so that it calls index.add() outside of the fetch handler.

[jeffposnick]

I can confirm that the icon check will trigger the service worker's fetch handler when the call to index.add() happens outside of the service worker.

In https://5de92abbb4ad155265985054--stoic-kepler-c046f7.netlify.com/ I've moved the calls to index.add() so that they happen in the window context when the web app loads. I've also moved the calls to index.delete() there, and basically just do a full sync between the state of the Cache Storage API and the state of the Content Index each time things load.

The relevant code is https://github.com/jeffposnick/samples/blob/72b8b334b0bd45e51cd553d75af07572d58be09a/web-share/src/js/contentIndexing.js#L20-L53 for those who are curious.

The explainer doc currently includes a couple of examples of calling index.add() from within a service worker, and that's fine as long as your icons actually exist on the remote server and don't require special fetch handling. When we write up the formal guidance for the API, I'll call out that as a caveat for folks who end up in the same situation as me.

Hardcoding '192x192' as the size, even though the underlying images might not have those dimensions, does not seem to be causing any validation problems.