Open Bug 1269469 Opened 9 years ago Updated 3 years ago

Remove the Downloads API

Categories

(Core :: DOM: Core & HTML, defect, P3)

defect

Tracking

()

REOPENED

People

(Reporter: ehsan.akhgari, Unassigned)

References

Details

(Whiteboard: btpp-backlog)

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
Closed: 9 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)
Priority: -- → P3
Component: DOM → DOM: Core & HTML
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.