1777919 - Crash in [@ nsWindow::NativeMoveResizeWaylandPopupCallback]

Status: RESOLVED FIXED

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

Description

[Gabriele Svelto [:gsvelto]]

Crash report: https://crash-stats.mozilla.org/report/index/8a25f125-6868-48e6-8c67-c43e50220703

MOZ_CRASH Reason: MOZ_DIAGNOSTIC_ASSERT(mWaitingForMoveToRectCallback) (Bogus move-to-rect callback! A compositor bug?)

Top 10 frames of crashing thread:

0 libxul.so nsWindow::NativeMoveResizeWaylandPopupCallback widget/gtk/nsWindow.cpp:1888
1 libgdk-3.so.0 _gdk_x11_get_window_child_info /usr/src/debug/gtk3-3.24.34-1.fc36.x86_64/gdk/x11/gdkasync.c:562
2 libgobject-2.0.so.0 g_signal_emit_valist /usr/src/debug/glib2-2.72.2-1.fc36.x86_64/gobject/gsignal.c:3406
3 libgobject-2.0.so.0 g_signal_emit_by_name /usr/src/debug/glib2-2.72.2-1.fc36.x86_64/gobject/gsignal.c:3595
4 libgdk-3.so.0 _gdk_x11_get_window_child_info /usr/src/debug/gtk3-3.24.34-1.fc36.x86_64/gdk/x11/gdkasync.c:562
5 libffi.so.8 ffi_call_unix64 
6 libffi.so.8 ffi_call_int.lto_priv.0 
7 libwayland-client.so.0 wl_closure_invoke.constprop.0 /usr/src/debug/wayland-1.20.0-4.fc36.x86_64/src/connection.c:1025
8 libwayland-client.so.0 dispatch_event.isra.0 /usr/src/debug/wayland-1.20.0-4.fc36.x86_64/src/wayland-client.c:1583
9 libwayland-client.so.0 wl_display_dispatch_queue_pending /usr/src/debug/wayland-1.20.0-4.fc36.x86_64/src/wayland-client.c:1971

Comment 1

[Gabriele Svelto [:gsvelto]]

The crash spike was spotted by clouseau

Comment 2

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

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

Comment 3

[Martin Stránský [:stransky] (ni? me)]

Yes, that's nightly only crash and something we need to watch and investigate.

Comment 4

[Marco Castelluccio [:marco]]

I guess it was spotted by Calixte's crash spikes tool, which is a different one than clouseau.

Comment 5

[Gabriele Svelto [:gsvelto]]

(In reply to Marco Castelluccio [:marco] from comment #4)

I guess it was spotted by Calixte's crash spikes tool, which is a different one than clouseau.

Is it? I thought they were the same. Do we have a bug for tracking crashes found by that tool?

Comment 6

[Marco Castelluccio [:marco]]

(In reply to Gabriele Svelto [:gsvelto] from comment #5)

(In reply to Marco Castelluccio [:marco] from comment #4)

I guess it was spotted by Calixte's crash spikes tool, which is a different one than clouseau.

Is it? I thought they were the same. Do we have a bug for tracking crashes found by that tool?

Comment 7

[Kevin Locke]

Attachment: autofill-profiles.json with 25 entries

I believe I'm able to reproduce this bug: https://crash-stats.mozilla.org/report/index/0e0033d4-79f7-49cc-b3cc-323940220720

For me the crash occurs during address autofill. Steps to reproduce:

1. Create a fresh profile.
2. Add information for several (~25) addresses to autofill (or save the attached autofill-profiles.json into the profile directory).
3. Navigate to a page with an address form, such as https://donate.mozilla.org/en-US/card/single/?source_page_id=3&currency=usd&amount=20.00
4. Enter the first letter of the autofill entries into the Email field (k for the attached file).
5. If a crash does not occur, press backspace and re-enter the letter. Repeat until crash occurs.

The last step often requires many attempts. Changing scroll position and/or mouse position may help if a crash does not occur after ~10 attempts.

I'm able to reproduce the crash with mutter 42.3 and sway 1.7.

Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=b8617ce97c450c28ece493550179b5a579cb6123&tochange=a6795c151e24eb326631b21d8f0944cc22d915a1 is consistent with being regressed by Bug 1777186 as already indicated.

Comment 8

[Jamie Nicol [:jnicol]]

I've hit this a couple times when hitting ctrl+tab to open the tab switcher. (The one which shows the thumbnails when "Ctrl+Tab cycles through tabs in recently used order" is enabled in preferences). Fedora 36, Gnome, Nvidia.

Comment 9

[Martin Stránský [:stransky] (ni? me)]

The triggering sequence is:

1. place popup by move-to-rect
2. hide popup (usually due to user action)
3. place popup again by gtk_window_move(). We use plain gtk_window_move() when popups with remote content is involved or if popups does not match layout setup.
4. show popup
5. we get move-to-rect callback from 1) which may not reflect new placement from 3)

Comment 10

[Martin Stránský [:stransky] (ni? me)]

After some testing it looks like we have the same popup coordinates on 3) and 5) anyway.

Comment 11

[Martin Stránský [:stransky] (ni? me)]

Attachment: Bug 1777919 [Wayland] Don't crash on bogus move-to-rect callback r?emilio

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9dcbc290d52a
[Wayland] Don't crash on bogus move-to-rect callback r=emilio

Comment 13

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/9dcbc290d52a

Comment 14

[Martin Stránský [:stransky] (ni? me)]

A correct fix here is to call gdk_window_move() which sets GdkWindow position_method to POSITION_METHOD_MOVE_RESIZE (Bug 1789581).

Comment 15

[Calixte Denizet (:calixte)]

(In reply to Gabriele Svelto [:gsvelto] from comment #5)

(In reply to Marco Castelluccio [:marco] from comment #4)

I guess it was spotted by Calixte's crash spikes tool, which is a different one than clouseau.

Is it? I thought they were the same. Do we have a bug for tracking crashes found by that tool?

Yep, the spike tool is different from Clouseau and there is no bug for tracking those crashes.