FYI 
Does this work in other browsers? Firefox (latest)
UA: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:64.0) Gecko/20100101 Firefox/64.0

We checked old version in https://www.browserling.com.
Bug started since 68 version, worked on (65,66,67).

> What is the expected behavior?
> All fetch events/resources requests should raise fetch event in service worker.

Can you explain why this is the expected behavior? This has come up in spec discussions before I think consensus has been the opposite and browsers can decide to go to a cache instead of the service worker (though it's not well specified). 

How are you serving the image?  The behavior is going to depend on your cache-control header value.

The html spec allows the browser to maintain a "high level" cache for images here:

https://html.spec.whatwg.org/#the-list-of-available-images

Anyway, high level caches like this will definitely prevent FetchEvent from being dispatched and that is by design.  If you don't want that behavior you need to use the cache-control header to say indicate the resource is not cacheable.

That being said, chrome will cache more resources than just images in its memory cache; e.g. stylesheets, etc.  That is not strictly spec'd, but its at least in the spirit of the image cache.

There was some previous discussion of allowing the service worker to mark resources as being exempt from only "high level" caches, but I think we concluded sites should just use cache-control header:

https://github.com/w3c/ServiceWorker/issues/962

So, are you setting cache-control:no-cache on the image?  If so and the memory cache is still holding on to it, then that might be worth investigating.

Hi,
By google developer docs, the service worker can control all of the pages under a specific scope:
"After the activation step, the service worker will control all pages that fall under its scope..."

By your answer, Chrome browser (Unlike other browsers) bypassing powers and prevents from the service worker to do his job.

Yes, I can control resource cache by setting cache-control to none but this is not the expected behavior.
My concern by setting cache-control to none, is that the service worker will have to decide which pages to save in cache instead of the server, which is quick "broken"... This may cause really bad user expreicence in case the browser does not support service worker or in case there was a problem installing the service worker.

Is there a way for the service worker to catch all of the resources requests ?

Thanks for your quick reply :)

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The cache-control has no bearing on if a page will be controlled or not.  If there is a matching service worker scope it will be controlled.  What the header does, though, is allow the resource to be cached or not at various places in the browser, network proxies, etc.

If the image cache or other high level cache is hit then the browser will not initiate a fetch at all.  If there is no fetch then there is no FetchEvent to dispatch to the service worker.  This is the same behavior you see without a service worker; the server is not consulted.

This is the standard at the moment.  If you disagree with the standard I suggest adding your point of view to the issue I linked above.  Again, it's:

https://github.com/w3c/ServiceWorker/issues/962

Agreed with c#8: this is better for https://github.com/w3c/ServiceWorker/issues/962