Open
Bug 1411000
Opened 7 years ago
Updated 9 months ago
Background scripts cannot open popups, such as triggering a file input dialog.
Categories
(WebExtensions :: General, enhancement, P3)
WebExtensions
General
Tracking
(Not tracked)
NEW
People
(Reporter: wisniewskit, Unassigned)
References
Details
Attachments
(1 file, 1 obsolete file)
The popup blocker currently silently blocks popups from background scripts/pages. This prevents the cleanest way that aswan and I believe would allow extensions to trigger a file-open dialog on a hotkey press or other such action (by calling .click on a file input attached to the background script's document).
This is because the principal of the background script does not have "popup" permissions. For instance, the attached patch solves this issue (though I'm not clear on whether it is the "right" way to fix this, or even suitable for landing as-is).
Reporter | ||
Updated•7 years ago
|
Flags: needinfo?(kmaglione+bmo)
Updated•7 years ago
|
status-firefox57:
--- → wontfix
Updated•7 years ago
|
Priority: -- → P3
Comment 1•7 years ago
|
||
My initial reaction is that this would be too broad in allowing popups where we already explicitly block some forms of (e.g. alert).
Is this specifically about file open dialogs? Why are they needed from the background?
Reporter | ||
Comment 2•7 years ago
|
||
Yes, it's about file open dialogs. I'd like to be able to listen for a hotkey command, and have it open such a dialog. Right now that would seem to be impossible, as attempts to open one on a content script are blocked (the event isn't considered "user-initiated" by the time I've sent a message via browser.tabs.sendMessage), nor the background scripts (where popups seem to simply be blocked regardless).
In addition, last time I checked I could not even call .click() a file input from the browser action (on Linux at least), because the action's popup vanishes when the file input dialog comes up, and by the time the user has chosen a file, so any changes events never trigger.
In other words, right now it's practically impossible to reliably open a file input dialog unless you get the user to click on an input, which is itself difficult to do reliably without opening a tab with such an input (to ensure that I even have a content script to work with).
I don't mind trying to restrict this to only file-open dialogs, but I'm not sure how to proceed. I'm guessing I would need to add a "file open dialog" permission that's similar to the "popup" permission my patch is adding (assuming we'd want to do that in the first place)?
Updated•7 years ago
|
Comment 3•7 years ago
|
||
I can think of useful use cases if this (file dialog) could work in the background script, and could provide better UX for some things. This currently should work fine from the sidebar. It seems like bug 1366330 would be the short path to working in panels. I'm just not convinced about opening the background to all popups via that permission.
Opening the background to file pickers would be a decent alternative, at least for my use case, to bug 1366330, since I wanted to send the data to the background anyway. I was using the file picker to import settings and configuration files which need to be sent to the background to be saved.
Updated•6 years ago
|
Product: Toolkit → WebExtensions
Updated•6 years ago
|
status-firefox57:
wontfix → ---
Flags: needinfo?(kmaglione+bmo)
Updated•2 years ago
|
Severity: normal → S3
Updated•9 months ago
|
Attachment #9384319 -
Attachment is obsolete: true
You need to log in
before you can comment on or make changes to this bug.
Description
•