[Colorway-Closet] Colorways Modal's initial size is too small on macOS
Categories
(Firefox :: Theme, defect, P1)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr91 | --- | unaffected |
| firefox-esr102 | --- | unaffected |
| firefox103 | --- | unaffected |
| firefox104 | --- | unaffected |
| firefox105 | --- | verified |
People
(Reporter: yshash, Assigned: dao)
References
(Regressed 1 open bug, Regression)
Details
(Keywords: regression, Whiteboard: [fidefe-2022-colorway-closet])
Attachments
(2 files)
Screen Shot 2022-08-12 at 10.34.34 AM.png
Changing the window size does not change width of the colorways modal.
STR
Open the colorways modal by launching it from either about:firefoxview or about addons
Resize the browser window to different widths
Current behaviour
Colorways Modal remains at fixed width and vertical scroll bars are always visible
Expected
Modal should be responsive , should shrink and grow based on the browser width.
OS : Mac OS version 12.5
Nightly : 105.0a1 (2022-08-12)
Hi, not sure what kind of information is requested from me here? But, yes, I can confirm this issue still exists in Nightly 105.0a1 (2022-08-12) (64-Bit) on macOS 12.5.
Thanks in advance for looking into it.
Adding the same "Blocks" and "Regressed by" bug numbers from bug 1783887.
|
||
Updated•2 years ago
|
|
||
Updated•2 years ago
|
|
||
Updated•2 years ago
|
|
|
||
Comment 3•2 years ago
|
||
Set release status flags based on info from the regressing bug 1783011
|
Assignee | |
Comment 4•2 years ago
•
|
||
There are several things going wrong here. First, the modal content window sets its height and width in em on the root element, but em is somewhat meaningless there because it's derived from font: message-box, and then we hardcode a different font-size on body: https://searchfox.org/mozilla-central/rev/dcb0cfb66e4ed3b9c7fbef1e80572426ff5f3c3a/toolkit/themes/shared/in-content/common-shared.css#261,268
So we need to move the font-size from body to :root.
Next, SubDialog.jsm takes that em value and uses it to set the outer frame size, which will translate to different sizes depending on the host window's font-size. So we need to translate that value from em to px before setting on the frame.
I'm hopeful that we don't have many existing sub dialogs depending on the current madness, but we'll have to see. :/
|
|
Assignee | |
Comment 5•2 years ago
|
||
Pushed by dgottwald@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/b2bdddc979f3 Fix up SubDialog sizing with em values. r=pbz
|
||
Comment 7•2 years ago
|
||
| bugherder | ||
|
||
Updated•2 years ago
|
|
|
||
Comment 8•2 years ago
|
||
I've managed to reporduce this issue using an affected Nightly build from 2022-08-12, on macOS 11.
The issue is verified as fixed on Nightly 105.0a1 (2022-08-16), across platorms: Win 10 x64, macOS 11 and Ubuntu 18.04 x64. The fix it seems that cannot be verified in Beta 105, since the associated colorways prefs are removed.
Description
•