Enable browserAction.openPopup without user interaction on all channels (Remove `extensions.openPopupWithoutUserGesture.enabled` preference)
Categories
(WebExtensions :: General, enhancement, P5)
Tracking
(firefox149 fixed)
| Tracking | Status | |
|---|---|---|
| firefox149 | --- | fixed |
People
(Reporter: oliver, Assigned: robwu)
References
(Depends on 1 open bug, Blocks 1 open bug)
Details
(Keywords: dev-doc-complete, Whiteboard: [addons-jira])
Attachments
(2 files)
In https://phabricator.services.mozilla.com/D139796, I updated the browserAction.openPopup API to remove the user gesture requirement. We initially put this behind a preference which by default is only set to true on Nightly. This allowed us to land the patch earlier before being sure of some more specific implementation details, such as if we will put this behind a permission.
This bug is to track removing that preference and enabling the change by default.
|
Assignee | |
Updated•3 years ago
|
|
||
Updated•3 years ago
|
|
||
Updated•3 years ago
|
|
||
Updated•3 years ago
|
|
||
Comment 2•1 year ago
|
||
This should be fixed for better Manifest V3 (but also not-persistent V2) compatibility.
Why?
Not persistent background scripts (where for example browser.contextMenus.onClicked.addListener lives) may need to load user options before calling browser.browserAction.openPopup, which won't work, due to asynchronous nature of storage.
(for example, user may want the context menu click to open new window, new tab, popup, or inject modal)
Note that Chrome 127 will finally have it implemented:
https://github.com/w3c/webextensions/issues/160#issuecomment-2147143055
It would be great help for devs to have this in upcoming Firefox ESR 128.
|
||
Comment 3•1 year ago
|
||
:robwu I am not sure where to put this so I'll start here. I've noticed that https://addons.mozilla.org/en-US/firefox/addon/icloud-passwords/ doesn't work well with this pref set to true, the UI is unusable as soon as we open the popup from within the extensions panel. It works relatively well when the extension is pinned to the nav-bar, though.
|
||
Comment 4•1 year ago
|
||
Hi! Curious about the status of this. I have a similar use case to juraj above. My intended behavior is to click an element in a popup window, close it in the on click handler and trigger the extension popup to open with browser.browserAction.openPopup. Having initially tried it, it seems that the browser would attempt to call browser.browserAction.openPopup from within the popup window context which leads to an error. Instead, I send a message with browser.runtime.sendMessage to send a message to the background script to trigger the browser.browserAction.openPopup call after a 100ms timeout. This works wonderfully in chrome, but I get a user gesture token error in firefox. The token seems to be lost in the message listener with or without the timeout. It would be nice if this requirement was removed or if someone can suggest a workaround to maintain cross-browser functionality.
|
|
Assignee | |
Updated•1 year ago
|
|
|
Assignee | |
Comment 5•1 year ago
|
||
(In reply to William Durand [:willdurand] from comment #3)
:robwu I am not sure where to put this so I'll start here. I've noticed that https://addons.mozilla.org/en-US/firefox/addon/icloud-passwords/ doesn't work well with this pref set to
true, the UI is unusable as soon as we open the popup from within the extensions panel. It works relatively well when the extension is pinned to the nav-bar, though.
This is tracked by bug 1799347.
|
|
Assignee | |
Comment 6•2 months ago
|
||
Ahead of enabling this by default, I checked the current cross-browser behaviors and shared the comparison with Chrome 143, Firefox 148 (with pref enabled) and the desired behavior at https://github.com/w3c/webextensions/issues/160#issuecomment-3774666519
The current behaviors in-tree are mostly similar to the desired behaviors. There are two main areas of behavior that needs to be updated:
- bug 1799347 - explicitly reject when the popup (or something else) is already open. There is some validation, but from testing I can still pop up a new popup when another extension popup is showing.
- bug 2011516 - reject
openPopup()for non-foreground windows.
After adding these explicit checks, we are ready to enable the feature by default on desktop.
For Android, bug 1817809 needs to be fixed.
The bugs not explicitly listed here can be worked on independently, with the intent to land them in the 149 cycle.
|
|
Assignee | |
Comment 7•2 months ago
|
||
|
||
Updated•2 months ago
|
|
|
Assignee | |
Comment 11•1 month ago
•
|
||
The dependency was inadvertently missing from the patch stack. I'm going to reland with https://bugzilla.mozilla.org/show_bug.cgi?id=2011516#c4 from bug 2011516 included.
|
||
Comment 12•1 month ago
|
||
|
|
||
Comment 13•1 month ago
|
||
|
||
Comment 14•1 month ago
|
||
Backed out for cauisng failures at test_ext_action_openPopup_multiple.html.
Backout link: https://hg-edge.mozilla.org/integration/autoland/rev/f98e369bc86f5d8949f40597b06907421ae76857
Push where failures started: https://treeherder.mozilla.org/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&revision=43b25e0614b5e27fcc88a04f28c3bb644d5773d2&selectedTaskRun=eCZ3kH9nSWO5_XlSmttMvw.0
Failure log: https://treeherder.mozilla.org/logviewer?job_id=548246737&repo=autoland&task=eCZ3kH9nSWO5_XlSmttMvw.0&lineNumber=5815
|
|
||
Comment 15•1 month ago
|
||
|
||
Comment 16•1 month ago
|
||
| bugherder | ||
|
|
Assignee | |
Updated•1 month ago
|
|
|
Assignee | |
Comment 17•1 month ago
|
||
The action.openPopup and browserAction.openPopup APIs are now available on non-Nightly channels from version 149, without requiring the user to set a pref. This should be documented in release notes, BCD, maybe mdn/content.
comment 6 has a bit more context on behaviors.
|
||
Comment 18•21 days ago
|
||
Documentation updates available in:
Description
•