1863409 - [Wayland] "Open Nightly in Troubleshoot Mode" dialog (aka safe mode) isn't tall enough for its content

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect, P2)

Description

[Daniel Holbert [:dholbert]]

Attachment: image.png

My STR just now:

1. Start Firefox and do something that hangs the parent process. (I don't have concrete linkable STR for this)
2. Force-quit Firefox by e.g. clicking the "X", waiting for the OS force-quit prompt, and clicking through to force-quit.
3. Repeat steps 1 and 2.
4. Start Firefox again.

ACTUAL RESULTS:
The Safe Mode aka Troubleshoot Mode prompt that appears isn't tall enough for its content. The button is clipped.

EXPECTED RESULTS:
The prompt should be tall enough for its content.

Comment 1

[Daniel Holbert [:dholbert]]

It looks like this is Wayland-specific. Sort-of.

Starting with a Firefox profile where I've crashed a few times such that I trigger this prompt...

• mozregression shows this behaving just like comment 0's screenshot as far back as this range:
  https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=89aa2c8696b7b10a4e71f95d4a468171b92bb828&tochange=cc33400f0ff80f0eada6c3aa637f37d247a3ff46
  ...which is what clued me in to the Wayland relevancy, due to Bug 1749174 being in there.
• And indeed, if I run with MOZ_ENABLE_WAYLAND=0, then I don't see this clipping in current Nightly.
• However, that might be because non-Wayland Nightly makes this dialog a little wider due to including minimize and fullscreen buttons in the titlebar (whereas Nightly-with-Wayland only has the "X" button and is hence a bit skinnier).

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: screenshot of dialog when starting Firefox with `MOZ_ENABLE_WAYLAND=0`

Comment 3

[:Gijs (he/him)]

Does this reproduce for you at all on macOS or Windows? If not, I wonder if this should move to Widget: GTK...

Comment 4

[Daniel Holbert [:dholbert]]

I haven't been able to summon this dialog on macOS yet (repeating the same steps that get me to it on Linux), so I'm not entirely sure. But yeah, given that the behavior here is somewhat wayland-specific, Widget:GTK makes sense.

Comment 5

[Martin Stránský [:stransky] (ni? me) (PTO, back on Feb 17)]

It's Wayland related - I've seen this bug for long time.

Comment 6

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

This bug has been marked as a regression. Setting status flag for Nightly to affected.

Comment 7

[Martin Stránský [:stransky] (ni? me) (PTO, back on Feb 17)]

Looks like the dialog is somehow missconfigured:

[Parent 511171: Main Thread]: D/Widget [7f52491d8f00]: nsWindow::Resize 400.000000 125.000000
[Parent 511171: Main Thread]: D/Widget [7f52491d8f00]: nsWindow::ResizeInt w:800 h:250
[Parent 511171: Main Thread]: D/Widget [7f52491d8f00]:   ConstrainSize: w:800 h;250
[Parent 511171: Main Thread]: D/Widget [7f52491d8f00]:   resized 0 aSize [800, 250] mLastSizeRequest [800, 250] mBounds [800, 250]
[Parent 511171: Main Thread]: D/Widget [7f52491d8f00]:   not moved or resized, quit
[Parent 511171: Main Thread]: D/Widget moz_container_wayland_map_event [7f52491d8f00]
[Parent 511171: Main Thread]: D/Widget moz_container_wayland_surface_set_scale_locked scale 2
[Parent 511171: Main Thread]: D/Widget [7f52491d8f00]: nsWindow::OnWindowStateEvent for 7f5249def460 changed 0x81 new_window_state 0x80
[Parent 511171: Main Thread]: D/Widget [7f52491d8f00]:  early return because no interesting bits changed
[Parent 511171: Main Thread]: D/Widget [7f52491d8f00]: nsWindow::OnWindowStateEvent for 7f52492b1b10 changed 0x81 new_window_state 0x80
[Parent 511171: Main Thread]: D/Widget [7f52491d8f00]: nsWindow::SetHasMappedToplevel(1)
[Parent 511171: Main Thread]: D/Widget [7f52491d8f00]:  quick return because IS_MOZ_CONTAINER(aWidget) is true
[Parent 511171: Main Thread]: D/Widget [7f52491d8f00]: configure event 0,0 -> 400 x 214 direct mGdkWindow scale 2 (scaled size 800 x 428)
[Parent 511171: Main Thread]: D/Widget [7f52491d8f00]: nsWindow::CheckForRollup() aAlwaysRollup 1
[Parent 511171: Main Thread]: D/Widget [7f52491d8f00]: nsWindow::OnWindowStateEvent for 7f5249def460 changed 0x80 new_window_state 0x0
[Parent 511171: Main Thread]: D/Widget [7f52491d8f00]:  early return because no interesting bits changed
[Parent 511171: Main Thread]: D/Widget [7f52491d8f00]: nsWindow::OnWindowStateEvent for 7f52492b1b10 changed 0x80 new_window_state 0x0
[Parent 511171: Main Thread]: D/Widget [7f52491d8f00]: nsWindow::SetHasMappedToplevel(1)
[Parent 511171: Main Thread]: D/Widget [7f52491d8f00]:  quick return because IS_MOZ_CONTAINER(aWidget) is true
[Parent 511171: Main Thread]: D/Widget moz_container_wayland_size_allocate [7f52491d8f00] 26,60 -> 348 x 125
[Parent 511171: Main Thread]: D/Widget moz_container_wayland_move [7f52491d8f00] 26,60
[Parent 511171: Main Thread]: D/Widget [7f52491d8f00]: nsWindow::OnSizeAllocate 26,60 -> 348 x 125
[Parent 511171: Main Thread]: D/Widget [7f52491d8f00]: nsWindow::DispatchResized() size [696, 250]
[Parent 511171: Main Thread]: D/Widget KeymapWrapper::SetFocusIn() surface 7f524d8275e0 ID 46 serial 59837
[Parent 511171: Main Thread]: D/Widget [7f52491d8f00]: configure event 0,0 -> 400 x 214 direct mGdkWindow scale 2 (scaled size 800 x 428)
[Parent 511171: Main Thread]: D/Widget [7f52491d8f00]: GetScreenBounds 52,120 -> 696 x 250, unscaled 26,60 -> 348 x 125

Comment 8

[Martin Stránský [:stransky] (ni? me) (PTO, back on Feb 17)]

The difference here is in window width. X11 has window size 400 x 125 while Wayland 348 x 125 so Wayland formats the text to four lines.
Looks like Wayland window is sized with decorations.

Comment 9

[Martin Stránský [:stransky] (ni? me) (PTO, back on Feb 17)]

Attachment: Bug 1863409 [Wayland] Count CSD decoration size borders for CSD windows with system titlebar off r?emilio

Right now we count CSD decoration size borders only for CSD windows with system titlebar on
which is incorrect as such windows also have CSD borders.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/782387a23b7b
[Linux] Count CSD decoration size borders for CSD windows with system titlebar off r=emilio

Comment 11

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/782387a23b7b

Comment 12

[Martin Stránský [:stransky] (ni? me) (PTO, back on Feb 17)]

Please revert this one due to regressions.
Thanks.

Comment 13

[Cristian Tuns]

Backed out as requested in Comment 12.
Backout link: https://hg.mozilla.org/integration/autoland/rev/98917be406eeca58f61d8aeaf62aa4cae5be2137

Comment 14

[Cristian Tuns]

Backout merged to central: https://hg.mozilla.org/mozilla-central/rev/98917be406ee

Comment 15

[Martin Stránský [:stransky] (ni? me) (PTO, back on Feb 17)]

Attachment: Bug 1863409 [Linux] Don't add CSD borders to undecorated windows r?emilio

Depends on D193787

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6847dbc7a82b
[Wayland] Count CSD decoration size borders for CSD windows with system titlebar off r=emilio
https://hg.mozilla.org/integration/autoland/rev/64014991c79c
[Linux] Don't add CSD borders to undecorated windows r=emilio

Comment 17

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/6847dbc7a82b
https://hg.mozilla.org/mozilla-central/rev/64014991c79c

Comment 18

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

Since nightly and release are affected, beta will likely be affected too.
For more information, please visit BugBot documentation.