Bug 157605 – [GTK] Browser plugins crash under Wayland

• Status: RESOLVED
• Resolution: FIXED
• Component: Plug-ins

[Michael Catanzaro]

The Evince browser plugin is crashing 100% when run under Wayland. See the downstream bug for a backtrace. (I can't paste it here like I usually do, because we haven't implemented paste yet. ;) Note that it goes through GtkPlug, which is sure to crash under Wayland.

Whatever code we have to disable windowed plugins in Wayland must not be working.

[Michael Catanzaro]

Truncated backtrace:

Thread 1 (Thread 0x7ffff7f0fac0 (LWP 15147)):
#0  0x00005555565b2cd0 in  ()
#1  0x00007ffff78bfbf3 in XGetWindowAttributes () at /lib64/libX11.so.6
#2  0x00007ffff233f894 in gtk_socket_realize () at /lib64/libgtk-3.so.0
#3  0x00007ffff0455617 in _g_closure_invoke_va () at /lib64/libgobject-2.0.so.0
#4  0x00007ffff046fea9 in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0
#5  0x00007ffff04704ff in g_signal_emit () at /lib64/libgobject-2.0.so.0
#6  0x00007ffff2309a9e in gtk_widget_realize () at /lib64/libgtk-3.so.0
#7  0x00007ffff230d0d8 in gtk_widget_set_parent () at /lib64/libgtk-3.so.0
#8  0x00007ffff4be7d74 in webkitWebViewBaseContainerAdd(_GtkContainer*, _GtkWidget*) () at /lib64/libwebkit2gtk-4.0.so.37
#9  0x00007ffff0458470 in g_cclosure_marshal_VOID__OBJECTv () at /lib64/libgobject-2.0.so.0
#10 0x00007ffff0455617 in _g_closure_invoke_va () at /lib64/libgobject-2.0.so.0
#11 0x00007ffff046fea9 in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0
#12 0x00007ffff04704ff in g_signal_emit () at /lib64/libgobject-2.0.so.0
#13 0x00007ffff20f5ff5 in gtk_container_add () at /lib64/libgtk-3.so.0
#14 0x00007ffff4c07f7c in WebKit::WebPageProxy::createPluginContainer(unsigned long&) () at /lib64/libwebkit2gtk-4.0.so.37
#15 0x00007ffff4c37a54 in WebKit::WebPageProxy::didReceiveSyncMessage(IPC::Connection&, IPC::MessageDecoder&, std::unique_ptr<IPC::MessageEncoder, std::default_delete<IPC::MessageEncoder> >&) ()
    at /lib64/libwebkit2gtk-4.0.so.37
#16 0x00007ffff49a9b91 in IPC::MessageReceiverMap::dispatchSyncMessage(IPC::Connection&, IPC::MessageDecoder&, std::unique_ptr<IPC::MessageEncoder, std::default_delete<IPC::MessageEncoder> >&) ()
    at /lib64/libwebkit2gtk-4.0.so.37
#17 0x00007ffff4a5ac0b in WebKit::WebProcessProxy::didReceiveSyncMessage(IPC::Connection&, IPC::MessageDecoder&, std::unique_ptr<IPC::MessageEncoder, std::default_delete<IPC::MessageEncoder> >&) ()
    at /lib64/libwebkit2gtk-4.0.so.37
#18 0x00007ffff49a5b3b in IPC::Connection::dispatchSyncMessage(IPC::MessageDecoder&) () at /lib64/libwebkit2gtk-4.0.so.37
#19 0x00007ffff49a5c2d in IPC::Connection::dispatchMessage(std::unique_ptr<IPC::MessageDecoder, std::default_delete<IPC::MessageDecoder> >) () at /lib64/libwebkit2gtk-4.0.so.37
#20 0x00007ffff49a63e6 in IPC::Connection::dispatchOneMessage() () at /lib64/libwebkit2gtk-4.0.so.37
#21 0x00007ffff42de8bd in WTF::RunLoop::performWork() () at /lib64/libjavascriptcoregtk-4.0.so.18
#22 0x00007ffff4301da9 in WTF::RunLoop::RunLoop()::{lambda(void*)#1}::_FUN(void*) () at /lib64/libjavascriptcoregtk-4.0.so.18
#23 0x00007ffff0181703 in g_main_context_dispatch () at /lib64/libglib-2.0.so.0
#24 0x00007ffff0181ab0 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#25 0x00007ffff0181b5c in g_main_context_iteration () at /lib64/libglib-2.0.so.0
#26 0x00007ffff074458d in g_application_run () at /lib64/libgio-2.0.so.0
#27 0x0000555555586954 in main ()

This backtrace is slightly different as it goes through GtkSocket rather than GtkPlug, but any rate WebKit should definitely not be using either when running under Wayland. See GNOME #766657 for a full backtrace.

[Carlos Garcia Campos]

createPluginContainer() starts in NetscapePluginX11::create() and that's called from NetscapePlugin::platformPostInitialize (in NetscapePluginUnix.cpp) which checks if PlatformDisplay::sharedDisplay().type() == PlatformDisplay::Type::X11. So I don't understand why that's happening. Could you check if we are returning PlatformDisplay::Type::X11 there in Wayland?

[Michael Catanzaro]

Hm, I guess we have two different plugin process crashes here. My backtrace (see the Red Hat bug) does not go through createPluginContainer at all.

[Carlos Garcia Campos]

(In reply to comment #3)
> Hm, I guess we have two different plugin process crashes here. My backtrace
> (see the Red Hat bug) does not go through createPluginContainer at all.

It doesn't matter the same applies to the geometry did change method that is specific to windowed plugins

[Michael Catanzaro]

(In reply to comment #2)
> createPluginContainer() starts in NetscapePluginX11::create() and that's
> called from NetscapePlugin::platformPostInitialize (in
> NetscapePluginUnix.cpp) which checks if
> PlatformDisplay::sharedDisplay().type() == PlatformDisplay::Type::X11. So I
> don't understand why that's happening. Could you check if we are returning
> PlatformDisplay::Type::X11 there in Wayland?

No, it's PlatformDisplay::Type::Wayland as expected. We never create the NetscapePluginX11 object.

[Michael Catanzaro]

The plugin process is creating a GtkPlug before it crashes, but I don't think it's being created anywhere inside WebKit. Yes, I know that doesn't make sense, but our only use of gtk_plug_new is in NetscapePluginX11.cpp in the constructor, and I've added WTFLogAlways and ASSERT_NOT_REACHED at the top of the constructor and it's definitely not being called. I even checked to make sure we're not passing GTK_TYPE_PLUG directly to g_object_new anywhere.

Anyway, PluginProxy::geometryDidChange and then NetscapePlugin::geometryDidChange are both being called before the crash. It's not so unexpected because this is the evince browser plugin, it's a windowed plugin; the code to stop us from creating a windowed plugin under Wayland must not be working.

Related: it's quite frustrating that we have the NetscapePlugin class under the WebProcess directory when it's also used by the plugin process; makes everything needlessly confusing. ;/

[Carlos Garcia Campos]

(In reply to comment #6)
> The plugin process is creating a GtkPlug before it crashes, but I don't
> think it's being created anywhere inside WebKit. Yes, I know that doesn't
> make sense, but our only use of gtk_plug_new is in NetscapePluginX11.cpp in
> the constructor, and I've added WTFLogAlways and ASSERT_NOT_REACHED at the
> top of the constructor and it's definitely not being called. I even checked
> to make sure we're not passing GTK_TYPE_PLUG directly to g_object_new
> anywhere.
> 
> Anyway, PluginProxy::geometryDidChange and then
> NetscapePlugin::geometryDidChange are both being called before the crash.
> It's not so unexpected because this is the evince browser plugin, it's a
> windowed plugin; the code to stop us from creating a windowed plugin under
> Wayland must not be working.
> 
> Related: it's quite frustrating that we have the NetscapePlugin class under
> the WebProcess directory when it's also used by the plugin process; makes
> everything needlessly confusing. ;/

Ah, it must be EvBrowserPlugin::setWindow() the one creating the plug. That shouldn't be called when we don't have an X11 implementation, but we can probably just fail the initialization when we don't have a platform implementation and the plugin is windowed.

[Carlos Garcia Campos]

Created attachment 280894 [details]
Patch

Could you try this patch, please?

[Michael Catanzaro]

Comment on attachment 280894 [details]
Patch

This fixes the crash and I even understand the code change, r+.

However, it is still impossible to view PDFs unless I uninstall the browser plugin, which is very bad. I see a black surface instead of the PDF. With the plugin uninstalled, Epiphany instead downloads the PDFs. This could be treated as a separate bug, though.

[Carlos Garcia Campos]

Committed r201921: <http://trac.webkit.org/changeset/201921>