[GTK] NPAPI code crashes on Wayland

[Michael Catanzaro]

With ENABLE_WAYLAND_TARGET=ON, we crash on extensions.gnome.org (with the GNOME Shell browser plugin installed) in WebPageProxy::createPluginContainer, attempting to use GtkSocket, which is illegal because it can only be used with a GdkX11Display. I guess we need to disable NPAPI support entirely when running under Wayland, unless someone volunteers to write code to make this work.

[Carlos Garcia Campos]

We used to disable NPAPI plugins when building the wayland target, I guess now we need to do a runtime check.

[Michael Catanzaro]

My plan is to build without NPAPI support for F23+, unless somebody wants to fix this with runtime checks, but it seems there are very many places that need the checks. I don't care about X11 support in F23+.

[Carlos Garcia Campos]

(In reply to comment #2)
> My plan is to build without NPAPI support for F23+, unless somebody wants to
> fix this with runtime checks, but it seems there are very many places that
> need the checks. I don't care about X11 support in F23+.

I guess we shouldn't care to fix bugs upstream that only happen in Fedora then.

[Carlos Garcia Campos]

Created attachment 257822 [details]
Patch

I guess this should be enough, I haven't tested it though. Could someone with wayland confirm this patch works?

[Michael Catanzaro]

(In reply to comment #3) 
> I guess we shouldn't care to fix bugs upstream that only happen in Fedora
> then.

I don't understand; if I disable NPAPI in Fedora, then the bug would not occur in Fedora, but only in other distros using Wayland.

(In reply to comment #4)
> Created attachment 257822 [details]
> Patch
> 
> I guess this should be enough, I haven't tested it though. Could someone
> with wayland confirm this patch works?

Thanks. When I looked at the plugin code, I thought it would need runtime checks in very many places besides this one. But if just that one check will work, then that is awesome. But I can't confirm it works, since my development build is crashing on start under Wayland. I will file another bug about this; it must be a recent regression, since this worked a few weeks ago.

[Michael Catanzaro]

Bug #147453

[Carlos Garcia Campos]

Created attachment 257917 [details]
Different patch

Zan suggested me to do that event earlier, so that not even the WebCore frame loader creates the plugin. So, I'm disabling the enable-plugins settings unconditionally for wayland.

[Zan Dobersek]

Comment on attachment 257917 [details]
Different patch

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

> Source/WebKit2/UIProcess/API/gtk/WebKitSettings.cpp:1600
> +    if (WebCore::PlatformDisplay::sharedDisplay().type() == WebCore::PlatformDisplay::Type::Wayland)
> +        return;

Should this throw a warning?

[Carlos Garcia Campos]

(In reply to comment #8)
> Comment on attachment 257917 [details]
> Different patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=257917&action=review
> 
> > Source/WebKit2/UIProcess/API/gtk/WebKitSettings.cpp:1600
> > +    if (WebCore::PlatformDisplay::sharedDisplay().type() == WebCore::PlatformDisplay::Type::Wayland)
> > +        return;
> 
> Should this throw a warning?

I don't think so, this will always be called on construction, because the default value of the setting is TRUE and all properties in WebKitSettings are construct properties.

[Carlos Garcia Campos]

Committed r187641: <http://trac.webkit.org/changeset/187641>

[Michael Catanzaro]

Thanks.

I think we should probably force disable the enable-java setting as well, in case some application queries that and gets confused that plugins are disabled but Java supposedly is enabled.