@Reporter: Could you please provide any such sample page/extension to triage it further from TE end.

Sorry, I wrote the result wrongly... 

What is actually happening is that the Extension is receiving the details for the event onHeadersReceived with a frameId = -1, when it was supposed to get a frameId >= 0.

So to update:

What steps will reproduce the problem?
1. Open a website with a service worker that handles requests with a FetchEvent Listener and responds with FetchEvent.respondWith(), let it install and activate;
2. Install any extension that uses webRequest API and log the callback for events of chrome.webRequest.onHeadersReceived;
3. Open a fresh tab, access the website on which the service worker is registered from step 1.


What is the expected result?
The extension should trigger a webRequest.onHeadersReceived upon loading the Response sent by event.respondWith() on the Service Worker, and log its details, having a frameId >= 0.


What happens instead of that?
chrome.webRequest.onHeadersReceived fires but mantains the frameId = -1, even if you navigate between pages.

-----------------

Note that if you check 'Bypass for Network' on DevTools > Application > Service Worker, it works as intended, having frameId >= 0 for both first load and navigations.

I'm also uploading here the source code for the simple example I made.

It is also available at: https://github.com/aledefreitas/chromium-issue-766433

Deleted: chromium-issue-766433.zip 5.6 KB

chromium-issue-766433.zip 5.6 KB Download

Thank you for providing more feedback. Adding requester "sc00335628@techmahindra.com" to the cc list and removing "Needs-Feedback" label.

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

I've noticed similar issue as described in the first report in Chrome 59.0.3071.115 (Ubuntu 17.04) - onHeadersReceived event is not fired for content fetched from service worker. I think it's quite serious, because in my case it prevents Adblock Plus from whitelisting ads for particular domain.

Steps to reproduce my case:
1. Install Adblock Plus (https://github.com/adblockplus/adblockpluschrome) in chrome.
2. Go to https://pogoda.onet.pl, make sure that service worker is installed and activated.
3. Whitelist pogoda.onet.pl domain in Adblock.
4. Open new tab and go to https://pogoda.onet.pl - you will see that ads are not displayed (even the 'friendly' ones).

The root cause of this behavior is the fact that chrome.webRequest.onHeadersReceived event is not fired for content fetched from SW (in my case it's document content) and Adblock Plus can't update site structure in a proper way. In Adblock Plus source code event listener is defined in this place: https://github.com/adblockplus/adblockpluschrome/blob/master/ext/background.js#L206.

I think the webRequest API and service worker interception never worked together.

We should address this with or after Network Servicification since Web Request and service worker request interception code will be changing a lot with that.

Any updates on this?

Hello! We just released our PWA on slate.com and are experiencing exactly this. We're losing tens of thousands of ad impressions every day because whitelisting Slate no longer works in ABP. Any updates on this? Suggestions on a work around? We are looking into potential fixes. Perhaps unloading the serviceworker entirely if the user has ABP installed (which isn't necessarily easy to check as far as I know.

 Issue 877249  has been merged into this issue.

I have a workaround for the problem on slate.com that Adblock Plus could use. It's quite basic, inject a content script that checks the Cache API used by the Service Worker for the current location.href. If present, delete the cache entry, unregister the Service Worker and reload. Contact me via email if you want the code.

From the point of view of Slate.com, you could stop workbox caching html pages and only cache static assets. ABP would then work as it keys off the main_frame to whitelist sites I believe.

Thanks Thomas for the workaround suggestion. We're using Google Workbox with the network first strategy, the idea is that readers with a valid connection will get the most recent content, but readers who are offline can at re-navigate to previously viewed pages and view the (possibly stale) content. 

Losing the ability to cache html pages would invalidate much of the reasons for using the service worker in the first place, it's too bad that we have to make a choice between serving ads to pay for the business and providing the best offline experience to our users.