chrome.downloads.* tests with legacy downloads

NEW
Unassigned

Status

()

Toolkit
WebExtensions: Request Handling
P5
normal
a year ago
2 months ago

People

(Reporter: aswan, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [downloads]triaged)

(Reporter)

Description

a year ago
Current tests for chrome.downloads.* use chrome.downloads.download() to initiate downloads.  But when a download is started from clicking a link on a web page, the download backend uses a very different code path (https://dxr.mozilla.org/mozilla-central/source/toolkit/components/jsdownloads/src/DownloadLegacy.js).
We should generalize the tests so that we can write the test logic once but execute them with either type of download (and then run both flavors when running all the tests).
(Reporter)

Updated

a year ago
Whiteboard: [downloads]

Comment 1

a year ago
More specifically, we should test that downloads started by the user through normal browsing are visible to the chrome.downloads listeners.

If it's easier to just run all the tests twice, go for it, but note that the Downloads.jsm tests already exercise both code paths for all the test cases, so the consistency of behavior for consumers of the API should be guaranteed already.

Updated

a year ago
Whiteboard: [downloads] → [downloads]triaged

Updated

6 months ago
Component: WebExtensions: Untriaged → WebExtensions: Request Handling
Priority: -- → P5
(Reporter)

Updated

2 months ago
See Also: → bug 1344822
You need to log in before you can comment on or make changes to this bug.