Remove use of PromptParent.openContentPrompt for handling prompts originated from a WebExtensions options page embedded in about:addons pages
Categories
(Toolkit :: Add-ons Manager, task, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox125 | --- | fixed |
People
(Reporter: rpl, Assigned: rpl)
References
(Blocks 1 open bug)
Details
(Whiteboard: [addons-jira])
Attachments
(3 files)
As a followup to Bug 1702059, which fixed a regression hit by prompt originated from WebExtensions options page embedded in the about:addons page by retaining the same behaviors and exact same prompt implementation that was used before the regression was it, we want now to followup further and not use anymore the PromptParent.openContentPrompt method to handle these prompts, because as part of Bug 1705440 we want to remove that implementation.
Gijs and I have discussed about this in the last few comments on Bug 1702059 (and over a short meeting to wrap up that discussion) and determined the following as the next step we want to aim for:
Bug 1702059 already included that approach as an "option 2" patch, but at the time we agreed to go for restoring the exact same prompt implementation that was used before the regression (likely because it was the less risky approach for fixing the regression), and so this new followup is tracking refreshing and finalizing that "option 2" patch to unblock the clean of the prompt internals tracked by Bug 1705440.
Updated•3 months ago
|
Assignee | ||
Comment 1•3 months ago
|
||
Updated•3 months ago
|
Assignee | ||
Comment 2•3 months ago
•
|
||
A screenshot that shows how the prompt triggered by the inline extension option page looks like with the patch attached applied.
Assignee | ||
Comment 3•3 months ago
|
||
Depends on D202237
Pushed by luca.greco@alcacoop.it: https://hg.mozilla.org/integration/autoland/rev/bdd79dc5ecab Remove use of PromptParent.openContentPrompt for handling prompts originated from extensions options page embedded in about:addons. r=Gijs https://hg.mozilla.org/integration/autoland/rev/34d8664ec96a Cleanup XUL stack from aboutaddons inline options custom element. r=willdurand,desktop-theme-reviewers,emilio
Comment 5•2 months ago
|
||
Backed out for causing bc failures @ toolkit/mozapps/extensions/test/browser/browser_html_options_ui.js
Backout link: https://hg.mozilla.org/integration/autoland/rev/f1fb325d13139b4b76787c19675d15d2816fd214
Assignee | ||
Comment 6•2 months ago
|
||
Sorry about that, the failure is triggered by the second patch in the stack (the one removing the XUL stack element), I'm updating that patch to include the necessary tweaks to the test case that hit the failure.
Pushed by luca.greco@alcacoop.it: https://hg.mozilla.org/integration/autoland/rev/683b127228e4 Remove use of PromptParent.openContentPrompt for handling prompts originated from extensions options page embedded in about:addons. r=Gijs https://hg.mozilla.org/integration/autoland/rev/1d361a405f31 Cleanup XUL stack from aboutaddons inline options custom element. r=willdurand,desktop-theme-reviewers,emilio
Comment 8•2 months ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/683b127228e4
https://hg.mozilla.org/mozilla-central/rev/1d361a405f31
Comment 9•25 days ago
|
||
Unrelated to the bug, but the second patch (https://hg.mozilla.org/integration/autoland/rev/1d361a405f31) fixes a long-standing visual issue with the options page.
Before the patch, there was a <stack>
wrapper (with min-height: 125px
) around the inline options browser (whose size is dynamic based on the option page's content). That gap is very prominent when the user prefers dark mode and the options page is rendered dark, because then that gap would have been painted white due to background-color: white
on the stack element: https://searchfox.org/mozilla-central/diff/b15e2861cb0d42c69251e1f644d33004b05b0622/toolkit/mozapps/extensions/content/aboutaddons.css#645-648
The second patch fixes this issue by removing the wrapper (and thus the gap). Side note: background-color: white
should have been background-color: Canvas
to support dark mode, which I just did as part of the fix for bug 1888866.
Description
•