Fix extension settings panel failing to open from tabs that are "unreachable"
Categories
(WebExtensions :: General, task)
Tracking
(firefox147 affected)
| Tracking | Status | |
|---|---|---|
| firefox147 | --- | affected |
People
(Reporter: cheff, Assigned: cheff)
References
Details
Attachments
(3 files, 1 obsolete file)
example-broken-extension-window.png
At zen browser, we have what would be called an "empty state" where no tab is technically selected, hence addons can't access it. This means that pinned extensions trying to be opened on that empty state will display a broken window, we would be thankful if this patch could be submitted to upstream firefox to reduce the patches we make to firefox every update. Let me know what you think, thanks!
|
Assignee | |
Comment 1•6 months ago
|
||
|
|
Assignee | |
Updated•6 months ago
|
|
|
Assignee | |
Comment 2•6 months ago
|
||
|
||
Comment 3•6 months ago
|
||
Comment on attachment 9528342 [details]
Bug 2000413 - Fix extension settings panel failing to open from tabs that are "unreachable"
Revision D262785 was moved to bug 1984420. Setting attachment 9528342 [details] to obsolete.
|
||
Comment 4•5 months ago
|
||
I have seen more than one bug requesting changes in Firefox to support customization by the Zen browser, citing Zen-specific reasons. To make it a bit easier to evaluate the requests, could you elaborate on your request here? And please include references/screenshots that allow one to relate the Zen feature to Firefox concept, if it is not already obvious to non-Zen devs/users.
Assuming that you are referring to the Extensions Panel tied to the Extensions Button in Firefox - that panel opens just fine in Firefox, when the user clicks on the button. Given that baseline, my next question is what's allegedly broken about it, and there is not enough information in this bug nor the patch to tell that.
an "empty state" where no tab is technically selected
Does this mean that there are no browser windows? Or that there is a (browser) window with tabs but none selected?
where no tab is technically selected, hence addons can't access it.
What does access mean in this context? If there is no tab, and presumably no content nor UI, what interest would add-ons have in this thing?
This means that pinned extensions trying to be opened on that empty state will display a broken window
Is "pinned extensions" here the same concept as in Firefox? I.e. an extension button on the toolbar?
What does "trying to be opened on that empty state" mean?
What does "display a broken window" mean?
This bug report
|
|
Assignee | |
Comment 5•5 months ago
|
||
Sure, I'll attach a reference issue that comes in with a video demonstration and the patch in question fixing such issue.
Does this mean that there are no browser windows? Or that there is a (browser) window with tabs but none selected?
Simply a tab that loads about:blank that is not visible to add-ons.
What does access mean in this context? If there is no tab, and presumably no content nor UI, what interest would add-ons have in this thing?
There is a tab selected, but as I said, its not visible to add-ons. I know its a bit confusing, but i'll attach the video of the issue as well so it can be better visualize.
Is "pinned extensions" here the same concept as in Firefox? I.e. an extension button on the toolbar?
Yes
What does "display a broken window" mean?
Its either nothing happening or a small square being opened (due to an error of trying to use the "selected tab" that in reality, the patched functions just return undefined).
|
|
Assignee | |
Comment 6•5 months ago
|
||
|
|
Assignee | |
Comment 7•5 months ago
|
||
|
|
Assignee | |
Updated•5 months ago
|
|
|
||
Comment 8•4 months ago
|
||
The extension action API and panel includes the expectation of there being a window with an active tab in the window. Extensions also use these APIs with that assumption. Even if you get ahead a bit more, extensions can and will be broken.
The proposed patch here adds several early returns to extension API internals that weaken the API guarantees for extension developers, without any apparent benefit to Firefox nor extensions. As I mentioned in a review on the patch, the suggested patch is not in a shape that can be merged.
A potential way to model the implementation in the extension API is to treat Zen's initial window not as a browser window, but a non-browser window that does not appear in the extension API. Although there is almost always a browser window around in Firefox, it is still possible for Firefox to be running without any such windows, such as on macOS, or when a non-browser window (e.g. Browser Console) is open after closing all browser windows. We do fix such bugs, e.g. recently at bug 2005963.
Since there is not anything actionable left here, I'm closing the bug. If you find issues that can realistically be encountered in Firefox, feel free to open a new bug with reproduction steps.
Description
•