Closed Bug 1579911 Opened 6 years ago Closed 5 years ago

Allow extensions to observe and modify requests created by downloads.download extension API

Categories

(WebExtensions :: Request Handling, enhancement, P3)

enhancement

Tracking

(firefox79 fixed)

RESOLVED FIXED
mozilla79
Tracking Status
firefox79 --- fixed

People

(Reporter: robwu, Assigned: aroraharsh010, Mentored)

References

Details

(Keywords: good-first-bug)

Attachments

(2 files)

STR:

  1. Load attached extension, e.g. at about:debugging
  2. 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:

  1. Downloads are created here: https://searchfox.org/mozilla-central/rev/8ecd15049c11eb753717a6631213ba5ecc90e123/toolkit/components/extensions/parent/ext-downloads.js#762-773
  2. which calls Downloads.createDownload
  3. which calls Download.fromSerializable.
  4. Since the "saver" property is not set, it defaults to "copy",
  5. which is handled by DownloadCopySaver.fromSerializable
  6. ... 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.

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