Allow extensions to observe and modify requests created by downloads.download extension API
Categories
(WebExtensions :: Request Handling, enhancement, P3)
Tracking
(firefox79 fixed)
Tracking | Status | |
---|---|---|
firefox79 | --- | fixed |
People
(Reporter: robwu, Assigned: aroraharsh010, Mentored)
References
Details
(Keywords: good-first-bug)
Attachments
(2 files)
STR:
- Load attached extension, e.g. at
about:debugging
- Click on the extension button to trigger a download. Confirm the download if asked.
Expected:
- The extension button should show "OK" (=webRequest event intercepted the request).
Actual:
- The extension button shows "FAIL" (=download completed without firing webRequest event).
This is not a regression and still happens on the latest Nightly (71).
This works in Chrome 76.
Being able to observe download requests through the webRequest API allows extensions to reliably detect the response headers and inspect/modify its response.
Extensions can already observe and modify requests that they created through <a download>
, so not being able to do the same with downloads created through downloads.download
is a bug.
If anyone is interested in fixing this:
- Downloads are created here: https://searchfox.org/mozilla-central/rev/8ecd15049c11eb753717a6631213ba5ecc90e123/toolkit/components/extensions/parent/ext-downloads.js#762-773
- which calls
Downloads.createDownload
- which calls
Download.fromSerializable
. - Since the "saver" property is not set, it defaults to "copy",
- which is handled by
DownloadCopySaver.fromSerializable
- ... which creates downloads with the system principal: https://searchfox.org/mozilla-central/rev/8ecd15049c11eb753717a6631213ba5ecc90e123/toolkit/components/downloads/DownloadCore.jsm#2049
To make sure that extensions can see their own requests, this should be created with the calling extension's principal instead. This could be done by forwarding context.principal
from step 1, all the way through step 6, and forward that principal to NetUtil.newChannel
via loadingPrincipal
.
Reporter | ||
Comment 1•6 years ago
|
||
This bug has a test case and a description of how to fix this. To make sure that this feature works as intended, a unit test should be added, for example by adding a test after https://searchfox.org/mozilla-central/rev/250f5cc9fb8bdcbb6b23d2a06acfd48addb2f99b/browser/components/extensions/test/browser/browser.ini#275
Documentation on getting started to contributing to the WebExtensions API implementation is available at
Description
•