2048884 - frameId is wrong in webRequest events triggered via importScripts

Status: NEW

(WebExtensions :: Untriaged, defect)

Description

[Juho Forsén [:jupenur]]

Steps to reproduce:

1. Build a website that creates a Worker. Have the worker load another script via importScripts.
2. Build an extension with a webRequest listener that matches the imported script.
3. Load the website in an iframe.
4. Observe the details parameter value passed to the webRequest listener.

Actual results:

details.tabId is nonzero and details.frameId is 0, indicating that the request is related to the main frame of a tab.

Expected results:

Both details.tabId and details.frameId should be nonzero; details.frameId should match the frame that invoked the Worker constructor.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'WebExtensions::Untriaged' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Juho Forsén [:jupenur]]

The same seems to apply to "nested" workers created by invoking the Worker constructor inside a worker: the script request's tabId is correct but the frameId is always 0.

Comment 3

[Rob Wu [:robwu]]

Workers are not in frames, we should return -1 here. Would that work for you?

While working on documentId recently (bug 1891478), I noticed that workers inexplicably have frameId 0 even when the request is not related to a frame. The patch stack for documentId was already rather large so I didn't touch the implementation, but I thought that it would be nice to eventually fix the issue - which is to set frameId to -1 for worker requests.

Relevant implementation is at https://searchfox.org/firefox-main/rev/bbdd22a8b58a05e5b269fe341b02ce11426c550f/toolkit/components/extensions/webrequest/ChannelWrapper.cpp#712-740

Comment 4

[Juho Forsén [:jupenur]]

The important part from my perspective is the ability to reliably distinguish a request coming from a worker initiated by an iframe from a request coming from the main frame. If frameId was -1 for the former, that would do it.

That said, the current behavior of fetch (as opposed to importScripts) in dedicated workers is to report the actual frameId of the frame that invoked the Worker constructor. If different types of requests from the same worker report a different frameId value, that seems very unexpected and confusing. Nothing I couldn't live with, though.

Comment 5

[vcarciu]

I am marking the issue as NEW based on comments from above. Thank you