1813960 - Save dialogue is transparent in Nightly

Status: RESOLVED FIXED

(Core :: Widget, defect)

Description

[bbhtt]

Attachment: ff-save-dialog.png

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/111.0

Steps to reproduce:

Download a file so that the "Save as" dialog appears eg. pdf

gtk3 3.24.36
gtk4 4.9.2
gnome-shell 43.2
Wayland with MOZ_ENABLE_WAYLAND=1

Actual results:

The dialogue is transparent

Expected results:

It shouldn't be transparent

Comment 1

[bbhtt]

Attachment: about:support

Comment 2

[bbhtt]

Mozregression shows this for me

$ mozregression --good 2023-01-20 --bad 2023-01-28

14:59.41 INFO: No more integration revisions, bisection finished.
14:59.41 INFO: Last good revision: 2c05658add65ba2f7513b2a76fe32be80c7c86e6
14:59.41 INFO: First bad revision: 1432fd8955ce7ee78eab40753eb15ee274045919
14:59.41 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=2c05658add65ba2f7513b2a76fe32be80c7c86e6&tochange=1432fd8955ce7ee78eab40753eb15ee274045919

$ mozregression --launch 1432fd8955ce7ee78eab40753eb15ee274045919 

 0:18.72 INFO: Running mozilla-central build built on 2023-01-27 05:27:22.806000, revision 4af274d4
 0:56.60 INFO: Launching /tmp/tmpaq1lj2ab/firefox/firefox
 0:56.60 INFO: Application command: /tmp/tmpaq1lj2ab/firefox/firefox -profile /tmp/tmpj8cc67_5.mozrunner
 0:56.62 INFO: application_buildid: 20230126212606
 0:56.62 INFO: application_changeset: 4af274d4ee613437631074174934b5739d002880
 0:56.62 INFO: application_name: Firefox
 0:56.62 INFO: application_repository: https://hg.mozilla.org/mozilla-central

<bad>

https://bugzilla.mozilla.org/show_bug.cgi?id=1810614 seems to be responsible

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

:emilio, since you are the author of the regressor, bug 1810614, could you take a look? Also, could you set the severity field?

For more information, please visit auto_nag documentation.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1810614

Comment 5

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1813960 - Move nsContainerFrame::SyncWindowProperties to PresShell. r=smaug,tnikkel,jfkthame

It's a more natural place for it to live, since it concerns only the
root view.

Clean up a bit while at it, and factor out the window size constraints,
which we're going to use momentarily.

Comment 6

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1813960 - Ensure that GetContentSize doesn't return a size under the window min size. r=smaug,tnikkel,jfkthame

Otherwise, if we end up with pref-size < min-size, we resize the content
to be the pref-size pixel size, but the window size clamping comes in,
and sets the window size to be bigger.

If we're lucky, the other dimension changes, and we trigger a size
update which fixes up things, but if we're not we end up with this bogus
state where the viewport frame has the wrong dimensions and the resize
never arrives.

Accounting for widget constraints fixes it.

Depends on D168461

Comment 8

[Emilio Cobos Álvarez (:emilio)]

[Tracking Requested - why for this release]: Looks terrible, affects all OSes (or at least Linux and Windows)

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/bc2870cfaf1d
Move nsContainerFrame::SyncWindowProperties to PresShell. r=smaug
https://hg.mozilla.org/integration/autoland/rev/88e051666f45
Ensure that GetContentSize doesn't return a size under the window min size. r=smaug

Comment 10

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/bc2870cfaf1d
https://hg.mozilla.org/mozilla-central/rev/88e051666f45