Bug 185818 – [GTK][Wayland] UI process crash when closing the window

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Carlos Garcia Campos]

This happens when a page containing a text field is loaded but the focus remains in the url bar when the window is closed. It can be easily reproducible with MiniBrowser:

 1 - Open MiniBrowser
 2 - Load google by typing the url in the bar
 3 - Close the window. Make sure the focus remains in the url bar, don't click the view mor move the mouse outside the window.

Thread 1 "MiniBrowser" received signal SIGSEGV, Segmentation fault.
__GI___libc_free (mem=0xaaaaaaaaaaaaaaaa) at malloc.c:3103
3103	malloc.c: No existe el fichero o el directorio.
(gdb) bt
#0  __GI___libc_free (mem=0xaaaaaaaaaaaaaaaa) at malloc.c:3103
#1  0x00007fff8e185dbd in reset_preedit (context=0x55555586ef10) at imwayland.c:107
#2  0x00007fffe5518fce in ffi_call_unix64 () from /usr/lib/x86_64-linux-gnu/libffi.so.6
#3  0x00007fffe551893f in ffi_call () from /usr/lib/x86_64-linux-gnu/libffi.so.6
#4  0x00007fffe8ce3184 in ?? () from /usr/lib/x86_64-linux-gnu/libwayland-client.so.0
#5  0x00007fffe8cdf9d9 in ?? () from /usr/lib/x86_64-linux-gnu/libwayland-client.so.0
#6  0x00007fffe8ce0ea4 in wl_display_dispatch_queue_pending () from /usr/lib/x86_64-linux-gnu/libwayland-client.so.0
#7  0x00007fffe8ce12cb in wl_display_roundtrip_queue () from /usr/lib/x86_64-linux-gnu/libwayland-client.so.0
#8  0x00007ffff36cfd5c in gdk_flush () at gdkdisplay.c:598
#9  0x00007ffff3bbbe7f in gtk_main () at gtkmain.c:1327
#10 0x0000555555561464 in main ()

This is because we are sending a notify-in to the IM context, but the focus is still in the URL bar. That confuses the wayland input manager that tries to free the text of the web view IM context that has already been deleted, instead of the URL bar one.

[Carlos Garcia Campos]

Created attachment 340839 [details]
Patch

[Michael Catanzaro]

(Previously reported as https://gitlab.gnome.org/GNOME/gtk/issues/1067.)

[Michael Catanzaro]

Comment on attachment 340839 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=340839&action=review

> Source/WebKit/UIProcess/gtk/InputMethodFilter.cpp:93
> +    if (enabled && m_page->isViewFocused())
>          notifyFocusedIn();

Do you think there's a GTK+ bug here, too? I guess so, because it seems really odd that this could avoid a crash deep in GTK+.

[Carlos Garcia Campos]

(In reply to Michael Catanzaro from comment #3)
> Comment on attachment 340839 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=340839&action=review
> 
> > Source/WebKit/UIProcess/gtk/InputMethodFilter.cpp:93
> > +    if (enabled && m_page->isViewFocused())
> >          notifyFocusedIn();
> 
> Do you think there's a GTK+ bug here, too? I guess so, because it seems
> really odd that this could avoid a crash deep in GTK+.

No, we are confusing GTK+ by saying our im context is the one with the focus when it's not.

[EWS Watchlist]

Comment on attachment 340839 [details]
Patch

Attachment 340839 [details] did not pass win-ews (win):
Output: http://webkit-queues.webkit.org/results/7760092

New failing tests:
http/tests/security/canvas-remote-read-remote-video-localhost.html

[EWS Watchlist]

Created attachment 340947 [details]
Archive of layout-test-results from ews205 for win-future

The attached test failures were seen while running run-webkit-tests on the win-ews.
Bot: ews205  Port: win-future  Platform: CYGWIN_NT-6.1-2.9.0-0.318-5-3-x86_64-64bit

[Carlos Garcia Campos]

Committed r232049: <https://trac.webkit.org/changeset/232049>