Open Bug 1344561 Opened 3 years ago Updated 3 months ago
consider supporting moz-extension:// service workers
Our position to date has been explicitly not to allow service workers for non-content origins. It seems most extension or addon systems have other methods designed for intercepting network traffic. Those seem more appropriate to use instead of using trying to (ab)use the service worker API. Loosening our origin restrictions on service workers increases the risk of security bugs. Can you describe the use case for a service worker in an extension?
It seems to me this should be possible with the webRequest API: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Intercept_HTTP_requests https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/WebRequest But it looks like that API does not support modifying the response body because chrome was worried about perf: https://bugs.chromium.org/p/chromium/issues/detail?id=104058#c19 Personally I'd rather see this feature added to webRequest so we don't have to add a bunch of special-case logic to our security-sensitive content API. If we are trying to maintain compat with chrome, though, that may not be possible. In any case, the ability to modify the response body is a missing feature. We should discuss how to handle that. If the decision is made we need service workers in WebExtensions it will probably not happen for a very long time. We're pretty buries on the service worker team trying to fix things for out multi-e10s efforts. Sorry!
Component: DOM: Service Workers → WebExtensions: Untriaged
Product: Core → Toolkit
Summary: ServiceWorker not allowed in a WebExtension → Support modifying network response bodies in WebExtension
When you are designing the API, please be aware of bug 1261585. I believe an API you would like to provide is similar to how nsITraceableChannel works today. We have currently big problems with how the nsITraceableChannel API is defined. The main problem is that consumers of that API wants to see the final data before we give them to the final listener (like HTML parser, image decoder, etc). But there are content decoders involved, which are normally added and running on the content process. But if the parent process wants to see the decoded content and intercept it (by means of ability to modify it), it becomes pretty complicated. Bug 1261585 outlines the problems and after several months we was not able to find a fix that would not be super-fragile or super-ugly and also work. Dragana know more than me at the moment (CCed) Please be careful when designing this API regarding our experience with nsITraceableChannel. Thanks.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1255894
Component: WebExtensions: Untriaged → WebExtensions: Request Handling
I spoke with a chrome engineer about what they do. I also talked with Shane a bit in the context of bug 1427747. I think I was confused about what was being asked for. I incorrectly thought the extension wanted to register a moz-extension:// origin service worker and receive FetchEvents for normal https:// requests from content pages. Basically I thought folks wanted this in order to implement something like: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/webRequest/filterResponseData I now understand (I think) that what is desired is a moz-extension:// origin service worker that receives FetchEvents only for network loads to its moz-extension:// origin. So the service worker is not chosen by the document's controlling service worker, but instead by the URL of the resource load. To do this we would have to do some largish things: 1. Expand URL protocol restrictions from http/https to include moz-extension. 2. Expose ServiceWorker binding objects in the background moz-extension windows. 3. Make ServiceWorkerManager smart enough to run the moz-extension service worker script in the WebExtensions process. 4. Make the nsIChannel code smart enough to do the foreign fetch style interception for moz-extension URLs. This might require a new channel implementation if we don't want to put this in SimpleChannel. I still think its very weird to do the normal service worker life cycle in the context of an extension. I would propose we also do something like: 5. Add the service worker script to the extension manifest 6. Fire install and activate as part of the extension installation process. If these fail then the extension installation would also fail. 7. Add code to remove any service workers for an extension if the extension is uninstalled. Things like (3) will require the service worker e10s refactor to complete first.
Status: RESOLVED → REOPENED
Depends on: ServiceWorkers-e10s
Resolution: DUPLICATE → ---
Summary: Support modifying network response bodies in WebExtension → consider supporting moz-extension:// service workers
You need to log in before you can comment on or make changes to this bug.