[macOS] In some about: pages, modal windows get resized
Categories
(Firefox :: Settings UI, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr102 | --- | unaffected |
firefox109 | --- | unaffected |
firefox110 | --- | verified |
firefox111 | --- | verified |
People
(Reporter: oardelean, Assigned: smaug)
References
(Regression)
Details
(Keywords: regression)
Attachments
(2 files)
(deleted),
video/quicktime
|
Details | |
(deleted),
text/x-phabricator-request
|
pascalc
:
approval-mozilla-beta+
|
Details |
Notes
- This behavior can also be seen in about:logins when trying to edit credentials with a Primary Password set up.
- Please see the attachment for more details.
Found in
- Nightly 111.0a1;
Affected versions
- Nightly 111.0a1;
- Firefox 110.0b3;
Tested platforms
- Windows 10;
- Ubuntu 22;
- macOS 12, macOS 11, macOS 10.15;
Affected platforms
- macOS 12, macOS 11, macOS 10.15;
Unaffected platforms
- Windows 10;
- Ubuntu 22;
Steps to reproduce
- Launch Firefox and go to about:profiles.
- Create a new profile.
- Click on the "Delete" button.
Expected result
- Modal window opens normally.
Actual result
- Modal window shifts down a few milimeters.
Regression range
- last good: 2023-01-10
- first bad: 2023-01-11
- pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=2732d1fd969c6f535568e69a056031a071fce01e&tochange=01f0f5a5c206cfc0b9111f17600a40a74227f8fe
- Potentially regressed by : Bug 1809057
Comment 1•2 years ago
|
||
That bug only touched windows code so has to be the other one.
Comment 2•2 years ago
|
||
Set release status flags based on info from the regressing bug 1807838
Assignee | ||
Comment 3•2 years ago
|
||
Updated•2 years ago
|
Comment 5•2 years ago
|
||
bugherder |
Assignee | ||
Comment 6•2 years ago
|
||
Comment on attachment 9313702 [details]
Bug 1811489 - MacOS shows visibly the changes to layout if sizeToContent is called after AppWindow::OnChromeLoaded, r=emilio
Beta/Release Uplift Approval Request
- User impact if declined: Glitch when opening some dialogs on Mac.
- Is this code covered by automated tests?: No
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: Yes
- If yes, steps to reproduce: See the first comment of the bug.
This definitely needs manual testing, since this is all about OS level painting and resizing of the windows.
- List of other uplifts needed: None
- Risk to taking this patch: Medium
- Why is the change risky/not risky? (and alternatives if risky): This code has proved to be very error prone in a way that if the ordering of the method calls isn't quite right, one may see visual glitches.
- String changes made/needed: NA
- Is Android affected?: No
Assignee | ||
Updated•2 years ago
|
Updated•2 years ago
|
Comment 7•2 years ago
|
||
Comment on attachment 9313702 [details]
Bug 1811489 - MacOS shows visibly the changes to layout if sizeToContent is called after AppWindow::OnChromeLoaded, r=emilio
I think this is not a good candidate for uplifting as this seems a bit of an edgecase, is an S3, somewhat risky and we are already at the mid beta cycle point, thanks for suggesting it though!
Assignee | ||
Comment 8•2 years ago
|
||
I'd somewhat like to reconsider this for beta. We have seen the regression bugs for this code filed very quickly., and the patch is now in Nightly.
Reporter | ||
Comment 9•2 years ago
|
||
Verified on Nightly 111.0a1(build ID: 20230126212606) on macOS 12 and macOS 10.15.
Comment 10•2 years ago
|
||
Comment on attachment 9313702 [details]
Bug 1811489 - MacOS shows visibly the changes to layout if sizeToContent is called after AppWindow::OnChromeLoaded, r=emilio
OK, let's take it in beta 7.
Comment 11•2 years ago
|
||
bugherder uplift |
Reporter | ||
Comment 12•2 years ago
|
||
Verified as fixed on Firefox 110.0b7(build ID: 20230129190147) on macOS 12 and macOS 10.15.
Description
•