Open Bug 1430479 Opened 7 years ago Updated 2 years ago

webRequest.onResponseStarted.addListener does not fire for cached responses

Categories

(WebExtensions :: Request Handling, defect, P3)

58 Branch
defect

Tracking

(Not tracked)

UNCONFIRMED

People

(Reporter: eros_uk, Unassigned)

Details

(Whiteboard: [webRequest])

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0
Build ID: 20180113220355

Steps to reproduce:

I have noticed that `webRequest.onResponseStarted.addListener()` does not fire on `discourse.mozilla.org`

Example code:
chrome.webRequest.onResponseStarted.addListener(e=> console.log(e),{ urls: ['<all_urls>'], types: ['main_frame'] });

Also tried with 'browser' and without `types: ['main_frame']` 

serviceworkers were pointed out. 

Looking at `about:serviceworkers`, Script Spec/Current Worker URL once loaded in a new tab, loaded from cache so  `webRequest.onResponseStarted.addListener` did not fire.

However, forced refreshing the tab caused the the `webRequest.onResponseStarted.addListener` to fire again once and then cached.

While the `webRequest.onResponseStarted.addListener` still fires on all those (main) sites with serviceworkers, it does not on `discourse.mozilla.org`

Unless the entire discourse is loaded only from the single serviceworker, the listener must have fired at some point, as it does on github, youtube, twitter and all other sites with serviceworkers.

I am not sure if the behaviour is intentional or accidental.
PS. if serviceworkers can bypass WE APIs, does that create a security risks?!! or at the very least, allow them to bypass extensions?!
Summary: webRequest.onResponseStarted.addListener does not fire on discourse.mozilla.org → webRequest.onResponseStarted.addListener does not fire for cached responses
Priority: -- → P3
Whiteboard: [webRequest]
I'm having the same / similar issue with webRequest API but in my case it doesn't look like it's cache related.

webRequest.onResponseStarted doesn't fire when I visit web page (like https://www.mozilla.org/) after entering URL in address bar (in fresh instance of Firefox). Cache state is irrelevant here, which I can confirm by looking at network connection info in developer toolbar and by inspecting details object passed to callback function (from_cache prop.). When I hit reload or visit some link form web page - event is fired for main_frame type as expected. I'm not sure but this bug escalated in latest releases of Firefox (version > 57) but haven't done any tests.

I also noticed that for e.g. stylesheet and scripts, event is always fired regardless of cache state.
Product: Toolkit → WebExtensions
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.