GNOME Bugzilla – Bug 738270
Evince browser plugin freezes firefox
Last modified: 2016-12-28 02:38:48 UTC
Created attachment 288179 [details] Blank black page rendered instead of pdf in firefox When trying to open any file in firefox that makes use of the evince browser plugin (eps, pdf, etc.) firefox freezes for a while (3-4 mins) and then loads a blank black page (screenshot attached). The evince plugin works just fine when used within epiphany though, so probably nothing wrong with my installation. Firefox version: 32.0.2 Evince version: GNOME Document Viewer 3.14.0
I guess it's because firefox doesn't support plugins using GTK+3, I think firefox should check that before loading the plugin, like WebKit used to do. But maybe we can do the check in evince as well, and return early with an error in NP_Initialize
*** Bug 739064 has been marked as a duplicate of this bug. ***
Actually, this has to be fixed in firefox, we can't check if the browser is using GTK2 or GTK3, but the browser can check if the plugin to be loaded uses GTK2 or GTK3.
Is there a upstream bug for mozilla? Firefox based on GTK3 should probably solve this, but this can least months or even years?
There is now.
Looks like the people at mozilla see this as a bug on the side of GNOME: https://bugzilla.mozilla.org/show_bug.cgi?id=1092126#c3 The think the loading of the plugin should fail within "NP_Initialize". Maybe in future the port of Firefox to GTK3 will fix this unnecessary.
Or could we store the plugin at a location where Firefox can't see or load it, while Epiphany or Midori can?
I don't know how to check from the plugin whether the browser loading it is using GTK+2 or not. In WebKit we have always done the check, by dlopen the module and looking for a gtk3 only symbol. Firefox has to dlopen the plugins in any case, so it would be very easy to check if the loaded plugin is incompatible even before calling NP_Initialize, and return early with an error in this case.
Are you in contact with the developers of Firefox? Because if neither side moves, nobody wins. Archlinux has just disabled the plugin, which I can understand. The maintainer don't want break Firefox. I think your plugin is a far better solution than PDF.js (native, fast, reliable), but I've seen it only for two days on my machine.
There's little I can do, as I said, the one loading a plugin can check the symbols of the library, but not the other way around. WebKit has always done that and it's very easy to do, so if firefox doesn't want to do it, I would suggest distros to patch firefox instead of disabling evince browser plugin. This is what we do in WebKit, FWIW: http://trac.webkit.org/browser/trunk/Source/WebKit2/Shared/Plugins/Netscape/NetscapePluginModule.cpp#L200
Hmm. I don't talked to the guys at Mozilla, but I'm afraid the main problem is that there is no motivation for them in taking action. I barley dare to suggest it, but why we don't store our own plugins in our very on plugin location? I suggest storing it at "/usr/lib/browser/plugins". At first I searched for the plugin releated stuff in the source of Epiphany, but this was wrong. The howl plugins stuff is handled by WebKit and there are the a bunch of directories defined directly inside the source[1]. At the top we can see "/usr/lib/browser/plugins" which sounds valid and reasonable, furthermore Firefox should not look there for a plugin [2] [3] [4]. [1]https://trac.webkit.org/browser/trunk/Source/WebCore/plugins/PluginDatabase.cpp#L388 [2]https://developer.mozilla.org/en-US/Add-ons/Plugins/Gecko_Plugin_API_Reference/Plug-in_Basics#How_Gecko_Finds_Plug-ins [3]https://developer.mozilla.org/en-US/Add-ons/Plugins/Gecko_Plugin_API_Reference/Plug-in_Development_Overview#Installing_Plug-ins [4]http://kb.mozillazine.org/Determining_plugin_directory_on_Linux We don't need to patch much source, we don't coordinate with Mozilla, will work for any WebKit based browser.
So basically: https://git.gnome.org/browse/evince/tree/configure.ac#n459 --- BROWSER_PLUGIN_DIR="\${libdir}/mozilla/plugins" +++ BROWSER_PLUGIN_DIR="\${libdir}/browser/plugins" The mentioned source from you [1] should secure also, that only Epiphany and Midori load the plugin, right? So we won't harm up Rekonq or Konqueror. [1] http://trac.webkit.org/browser/trunk/Source/WebKit2/Shared/Plugins/Netscape/NetscapePluginModule.cpp#L200
*pump* Had the very same crash when opening an email with HTML and image rendering in KMail of KDE and when opening http://build.opensuse.org/ in konqueror. See: https://bugs.kde.org/show_bug.cgi?id=343446 It boils down to gtk+ not checking for NULL pointer when dereferencing in line 173: # nl -ba /var/tmp/portage/x11-libs/gtk+-2.24.25-r1/work/gtk+-2.24.25/gdk/x11/gdkdisplay-x11.c | grep -C 4 '^ *173' 169 170 display = g_object_new (GDK_TYPE_DISPLAY_X11, NULL); 171 display_x11 = GDK_DISPLAY_X11 (display); 172 173 display_x11->use_xshm = TRUE; 174 display_x11->xdisplay = xdisplay; 175 176 #ifdef HAVE_X11R6 177 /* Set up handlers for Xlib internal connections */ For "display_x11 = GDK_DISPLAY_X11 (display);" - line 171 - returning NULL. Please reopen bug and hand it over to the gtk+ group.
Created attachment 299110 [details] [review] Check supported Gtk+ version Hi, I'm sorry for attaching this to a closed bug but it is related to the problem. Maybe we could check supported version of Gtk+ in NPP_New() and return error if it is NPNVGtk12 or NPNVGtk2. Unfortunately, NPAPI doesn't have a NPNVGtk3 but webkit uses an integer value anyway. This would need a change in webkit since it always returns 2 in NPN_GetValue for NPNVToolkit variable. It would need to return 3 for the case when the plugin loads gtk3 library. Specifically it needs to propagate the requiresGtk2 member of PluginModuleInfo to NPN_GetValue. Another problem is that firefox doesn't handle well the situation when NPP_New() returns an error but it doesn't freeze at least
It's ridiculous that we have to do so many changes everywhere when it's so easy to fix in firefox. I think the problem is in firefox and more general than the Evince browser plugin, because it means you can freeze firefox just by writing a simple NPAPI plugin that links to gtk+3. Isn't it possible to disable plugins individually in firefox? If they don't want to support GTK+3 plugins, nor fix the browser to not freeze when a GTK+3 plugin is loaded, I recommend firefox users to blacklist the evince browser plugin, or switch to a web browser that doesn't freeze.
(In reply to Marek Kašík from comment #14) > Created attachment 299110 [details] [review] [review] > Check supported Gtk+ version > > Hi, I'm sorry for attaching this to a closed bug but it is related to the > problem. > > Maybe we could check supported version of Gtk+ in NPP_New() and return error > if it is NPNVGtk12 or NPNVGtk2. Unfortunately, NPAPI doesn't have a NPNVGtk3 > but webkit uses an integer value anyway. > This would need a change in webkit since it always returns 2 in NPN_GetValue > for NPNVToolkit variable. It would need to return 3 for the case when the > plugin loads gtk3 library. Specifically it needs to propagate the > requiresGtk2 member of PluginModuleInfo to NPN_GetValue. I think this is a good idea in any case, please file a bug report in Webkit (add me to the CC) and I'll fix it.
Wouldn't this break Gtk2 plugins in Webkit Gtk? Can someone run Gtk2 and Gtk3 plugins in Webkit right now?
Created attachment 299175 [details] [review] Check supported Gtk+ version > I think this is a good idea in any case, please file a bug report in Webkit > (add me to the CC) and I'll fix it. I've filled the bug here: https://bugs.webkit.org/show_bug.cgi?id=142616. I've also improved the evince patch a little so that it check the supported gtk version also in NP_Initialize() and can fail sooner (it seems that at least WebKit supports calling of NPN_GetValue() with NULL instance - https://bugs.webkit.org/show_bug.cgi?id=18892).
Carlos?