downloads.download() unnecessarily requires an active browser window
Categories
(WebExtensions :: General, defect, P3)
Tracking
(firefox149 fixed)
| Tracking | Status | |
|---|---|---|
| firefox149 | --- | fixed |
People
(Reporter: robwu, Assigned: robwu)
References
Details
(Whiteboard: [addons-jira])
Attachments
(1 file)
As part of fixing bug 2005953, I created a xpcshell test to serve as a regression test. The test calls browser.downloads.download() with saveAs:true to open a file picker, but that API call failed because xpcshell tests do not have browser windows, but the ext-downloads.js implementation looks up one at https://searchfox.org/firefox-main/rev/d0cad31feab6676471f18793c8feff24b2434ab0/toolkit/components/extensions/parent/ext-downloads.js#931
That issue was hit before in bug 1623704, which relaxed the original implementation (strictly expecting a Firefox browser window) to the current one (expecting any platform-specific "browser" window).
This logic does not only fail in xpcshell tests, it would also fail if Firefox is running without a browser window.
I looked into the implementation, and the window (specifically its browsingContext) usage is as follows:
- to look up the
canOpenModalPickerflag. Note that this flag is always true for chrome windows. - to look up the global to associate DOM
Fileinstances when used in the file picker. This is not relevant for the usage in the downloads API. - to run some content analysis checks on Windows that are not relevant to chrome-privileged file pickers.
- to check if the caller is in private browsing mode in
nsFilePicker::IsPrivacyModeEnabled().
Since ext-downloads.js uses an arbitrary browser window, this may not be very effective
None of these uses depend on the input being a browser window. I think that we can safely fall back, or even only use, the (chrome privileged) window that owns the extension context (browser window for extension tabs/popups, or the headless window for background contexts).
| Assignee | ||
Comment 1•3 months ago
|
||
A xpcshell test for this behavior will be added in bug 2005953.
Updated•3 months ago
|
Updated•3 months ago
|
Updated•3 months ago
|
Comment 3•2 months ago
|
||
| bugherder | ||
| Assignee | ||
Comment 4•2 months ago
|
||
This was not fixed yet, the patch was reverted in https://bugzilla.mozilla.org/show_bug.cgi?id=2005953#c8
This confusion caused be to reland the other patch without this patch, which resulted in another revert at https://bugzilla.mozilla.org/show_bug.cgi?id=2005953#c8
analysis: https://bugzilla.mozilla.org/show_bug.cgi?id=2005953#c10
Updated•2 months ago
|
Comment 6•2 months ago
|
||
| bugherder | ||
Description
•