Remove the Downloads API

REOPENED
Unassigned

Status

()

P3
normal
REOPENED
3 years ago
6 months ago

People

(Reporter: Ehsan, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: btpp-backlog)

(Reporter)

Description

3 years ago
Fabrice, can we do this now?
Flags: needinfo?(fabrice)
Blocks: 1266035
Whiteboard: btpp-backlog
No, we need to keep this one. We patched it on Pine to be chrome-only though.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Flags: needinfo?(fabrice)
Resolution: --- → WONTFIX
Does b2g really need it to be a DOM API though?  Chrome-privileged main process code has Downloads.jsm[1] available and for sorta-privileged code in any process there's also the Downloads WebExtensions API[2] available.

The current uses in the kanikani branch continue to be:
- Get notified of new downloads.
- Hear about state changes to those downloads
- Be able to remove/cancel the download.
Both of those APIs provide these mechanisms.

Notably, the b2g/gaia code does not leverage the download database, opting instead to maintain its own DataStore (which maybe is broken now?).  Accordingly, the coupling is arguably already quite limited.

1: https://developer.mozilla.org/en-US/docs/Mozilla/JavaScript_code_modules/Downloads.jsm
2: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/downloads
Status: RESOLVED → REOPENED
Flags: needinfo?(fabrice)
Resolution: WONTFIX → ---
We don't want to rely on chrome .jsm or xpcom in gaia, even when served from chrome:// uris.

Using the Downloads WebExtensions api would be great, I didn't know about this one! I'll be fine with going this way once we have WebExtensions available again in b2g (they used to be shipped as apps).
Flags: needinfo?(fabrice)

Updated

6 months ago
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.