Cannot use file pickers in extension background pages any more
Categories
(WebExtensions :: General, defect)
Tracking
(firefox-esr115 unaffected, firefox-esr128 unaffected, firefox135 unaffected, firefox136 verified, firefox137 verified)
Tracking | Status | |
---|---|---|
firefox-esr115 | --- | unaffected |
firefox-esr128 | --- | unaffected |
firefox135 | --- | unaffected |
firefox136 | --- | verified |
firefox137 | --- | verified |
People
(Reporter: robwu, Assigned: robwu)
References
(Regression)
Details
(Keywords: regression, Whiteboard: [addons-jira])
Attachments
(2 files)
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
phab-bot
:
approval-mozilla-beta+
|
Details | Review |
While looking at bug 1949092, I noticed that due to the patches for bug 1837963, that extension background pages cannot spawn pickers such as <input type="file">
any more.
This was not an intentional change, so let's add test coverage and figure out the desired behavior.
Spawning a picker dialog requires user interaction, which is presumed to be unlikely for hidden tabs.
It is however possible for extension APIs to receive such user interaction, e.g. as seen below. Such patterns are most likely to exist in hidden extension pages (background pages and devtools pages) than regular hidden (extension) tabs.
browser.browserAction.onClicked.addListener(() => {
let input = document.createElement("input");
input.type = "file";
document.body.append(input);
input.click();
});
Updated•6 months ago
|
Assignee | ||
Comment 1•6 months ago
|
||
Since Firefox 136, pickers cannot be opened from non-focused tabs.
Unintentionally, background pages of extensions and devtools pages of
extensions were also affected, because their browsers are embedded in a
hidden XUL window, which is considered not focused.
This patch updates CanonicalBrowsingContext::CanOpenModalPicker to allow
pickers to be opened from specific hidden extension browsers again.
To evaluate the feasibility of enforcing the restriction for hidden
background pages, this patch puts the restriction behind a pref,
enabled by default on Nightly only. If no signs of broken extensions
are reported for a few releases, we can set the pref by default, to
enforce the restriction (and document the change accordingly).
After another few releases we can evaluate whether to enforce the
restriction permanently (effectively removing the exception from
this patch) or to revert the pref.
Assignee | ||
Comment 2•6 months ago
|
||
The patch depends on Windowless()
with the semantics from the patch to bug 1937603. I'm marking this dependency more clearly because I intend to uplift the patch stack of this bug and bug 1949092 to beta, to resolve a regression before it hits release.
Assignee | ||
Comment 3•6 months ago
|
||
Since Firefox 136, pickers cannot be opened from non-focused tabs.
Unintentionally, background pages of extensions and devtools pages of
extensions were also affected, because their browsers are embedded in a
hidden XUL window, which is considered not focused.
This patch updates CanonicalBrowsingContext::CanOpenModalPicker to allow
pickers to be opened from specific hidden extension browsers again.
To evaluate the feasibility of enforcing the restriction for hidden
background pages, this patch puts the restriction behind a pref,
enabled by default on Nightly only. If no signs of broken extensions
are reported for a few releases, we can set the pref by default, to
enforce the restriction (and document the change accordingly).
After another few releases we can evaluate whether to enforce the
restriction permanently (effectively removing the exception from
this patch) or to revert the pref.
Original Revision: https://phabricator.services.mozilla.com/D239046
Updated•6 months ago
|
Assignee | ||
Updated•6 months ago
|
Comment 4•6 months ago
|
||
beta Uplift Approval Request
- User impact if declined: Extensions cannot open file picker (or color picker) from their background page or devtools page
- Code covered by automated testing: yes
- Fix verified in Nightly: no
- Needs manual QE test: no
- Steps to reproduce for manual QE testing: QA not needed; but if someone wants to: install any extension with an extension button (browserAction), e.g. https://addons.mozilla.org/en-US/firefox/addon/display-_anchors/ and visit about:debugging. Press Inspect and run the code snippet from comment 0. Then click the extension button. A file picker should appear.
- Risk associated with taking this patch: Low; Note (for the lack of better place in the uplift form): this patch depends on https://phabricator.services.mozilla.com/D239099 and https://phabricator.services.mozilla.com/D239198
- Explanation of risk level: This restores the behavior from Firefox 135 and earlier, and includes a pref to toggle the logic.
- String changes made/needed: None
- Is Android affected?: yes
Updated•6 months ago
|
Updated•6 months ago
|
Comment 8•5 months ago
|
||
Verified as Fixed. Tested on the latest Nightly (137.0a1/20250224170755) and Beta (136.0b10/20250223143918 from https://treeherder.mozilla.org/jobs?repo=mozilla-beta&revision=55180bee8d857d8bd454040efe47889ccd8fe93e) under Windows 10 and Ubuntu 24.04 LTS.
Running the snippet from Comment 0 and then clicking the extension button will open the file picker, confirming the fix.
Note that on Nightly the pref to toggle the restriction logic was set to “true” by default and I had to toggle it to “false” in order to verify the fix. With the pref set to "true", clicking the extension button after running the snippet, will not open the filer picker. On Beta the pref was set by default to “false”.
Description
•