Closed Bug 1092126 Opened 10 years ago Closed 7 years ago

Disable loading gtk3 plugins (e.g. evince browser plugin) instead of freezing

Categories

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

32 Branch
x86_64
Linux
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: badshah400, Unassigned)

References

Details

(Whiteboard: tpi:+)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:32.0) Gecko/20100101 Firefox/32.0 Build ID: 2014092000 Steps to reproduce: I use Firefox version 32.0.2 on GNOME 3.14 (openSUSE Linux 13.2). Since GNOME 3.14 evince ships a document viewer plugin of its own which handles pdf, eps, djvu and a host of other formats supported by evince. Unfortunately since this is a gtk3 plugin (and I am using Firefox 32.0.2), every time firefox tries to launch the plugin it freezes until I kill the browser manually. I opened a bug over at bugzilla.gnome.org [1], but was told that this might be in reality a Firefox bug since the browser should check if a plugin is gtk3 based and then disable it because gtk3 isn't supported yet. Apparently it doesn't do that. [1] https://bugzilla.gnome.org/show_bug.cgi?id=738270 Actual results: Try to open eps/djvu file within browser (after making sure the evince plugin "libevbrowserplugin.so" is enabled) Expected results: Firefox freezes completely. Have to kill process.
Component: Untriaged → Widget: Gtk
Product: Firefox → Core
Benjamin/Karl: can we do this? And isn't this a plugin rather than a widget::gtk bug?
Flags: needinfo?(karlt)
Flags: needinfo?(benjamin)
As far as I know there's no API for asking a plugin this. I believe the plugin is responsible for returning a failure from NP_Initialize if it is incapable of running in the host environment. If there is a different protocol that we should be following for negotiating this, we should document it somewhere.
Flags: needinfo?(benjamin)
(In reply to :Gijs Kruitbosch from comment #1) > Benjamin/Karl: can we do this? Perhaps it is possible with dlopen and dlsym tricks to search for GTK3 symbols. Not sure. > And isn't this a plugin rather than a widget::gtk bug? Yes, it is a bug in the plugin. There is no support for plugins that load GTK3, and no intention of providing such support. http://hg.mozilla.org/mozilla-central/annotate/5dde8ea48fef/dom/plugins/base/npapi.h#l425
Flags: needinfo?(karlt)
Is there a reason not to use the blocklist to deal with this?
Is this potentially working now that we support gtk3?
Flags: needinfo?(karlt)
(In reply to Jim Mathies [:jimm] from comment #5) > Is this potentially working now that we support gtk3? No, GTK3 plugins are still not supported. Please blocklist the plugin.
Flags: needinfo?(karlt) → needinfo?(jmathies)
Flags: needinfo?(jmathies)
Priority: -- → P2
Whiteboard: tpi:+
It looks like GNOME will be dropping the evince browser plugin in GNOME 3.24; however there are distros that include the plugin that will be supported for several more years. https://git.gnome.org/browse/epiphany/commit/?id=9e1457f64
Never mind. The epiphany developers reverted that change so the evince browser plugin does not look like it's going away for now.
This should be covered by bug 1269807.
Depends on: npapi-eol
Fixed by bug 1269807.
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.