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)
Screenshot from 2024-02-20 16-55-24.png
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•1 year ago
|
|
Assignee | |
Comment 1•1 year ago
|
||
|
||
Updated•1 year ago
|
|
|
Assignee | |
Comment 2•1 year 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•1 year ago
|
||
Depends on D202237
|
||
Comment 5•1 year 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•1 year 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.
|
||
Comment 8•1 year ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/683b127228e4
https://hg.mozilla.org/mozilla-central/rev/1d361a405f31
|
||
Comment 9•1 year 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
•