GNOME Bugzilla – Bug 766776
Kill browser plugin
Last modified: 2019-01-09 17:47:08 UTC
The browser plugin is crashy and broken; there are dozens of bugs filed against it here and nobody is looking at them. Chrome has already dropped support for NPAPI plugins, Firefox is going to do so before the year is out. The only browser that will be left supporting NPAPI is Epiphany, but I intend to blacklist this plugin specifically due to the high number of crash reports. We could continue to "maintain" here a useless plugin that works in no browsers, or we could just delete it.
Created attachment 328352 [details] [review] Remove the browser plugin The browser plugin is crashy and broken; there are dozens of bugs filed against it on Bugzilla and nobody is looking at them. Chrome has already dropped support for NPAPI plugins, Firefox is going to do so before the year is out. The only browser that will be left supporting NPAPI is Epiphany, but I intend to blacklist this plugin specifically due to the high number of crash reports. We could continue to "maintain" here a useless plugin that works in no browsers, or we could just delete it.
Note: this is intended for GNOME 3.22, since GNOME Software has grown support for handling shell extensions. Somebody else will need to care to extensions.gnome.org.
(In reply to Michael Catanzaro from comment #1) > Remove the browser plugin That has been the plan for a while now, but the replacement should be ready before we kill off the plugin. Currently installed extensions show up in Software, but nothing more - we'll need search results and installation as well ...
*** Bug 729452 has been marked as a duplicate of this bug. ***
Note that support for browser plugins has been removed from Epiphany 3.23.1.
(In reply to Michael Catanzaro from comment #5) > Note that support for browser plugins has been removed from Epiphany 3.23.1. Note that I got in trouble for this and reverted the change.
Hello, What do you think about merging chrome-gnome-shell [1] native messaging app to GNOME Shell codebase as replacement for NPAPI plugin? Currently, chrome-gnome-shell supports all major browsers: Google Chrome/Chromium, Vivaldi, Firefox and Opera. See also: https://blogs.gnome.org/ne0sight/2016/12/25/how-to-install-gnome-shell-extensions-with-firefox-52/ [1] https://wiki.gnome.org/Projects/GnomeShellIntegrationForChrome
P.S.: As for signed browser extensions please note, that I'm twice [1][2] sent message to Release Team asking to take control of release accounts for Browsers's Stores and also sent message to Foundation Board last week with offer to transfer ownership of extensions published at Browsers Stores. [1] https://mail.gnome.org/archives/release-team/2016-March/msg00024.html [2] https://mail.gnome.org/archives/release-team/2016-December/msg00026.html
I guess the twist of fate here is that my decision to drop support for NPAPI plugins was reverted, so we actually still need the plugin for our browser. And the plugin actually works reliably now that Carlos Garcia fixed some refcounting bug. And now that you're maintaining the extensions website, we don't actually want to kill the website anymore; that was only desirable when nobody was working on it and it was super broken for years. So actually I'm OK with the status quo now; things have improved hugely in the past couple of months. Feel free to catch me on IRC or epiphany-list if you want to talk about an NPAPI replacement. I don't think it can use WebExtensions as that'd be a big project that nobody seems to be interested in working on, but it should be relatively straightforward to throw together some JS API that's only made available to extensions.gnome.org if you want to drop the plugin. We do still need to get chrome-gnome-shell into distros, but I don't see any particular reason to include it in the gnome-shell codebase; it can live happily as a separate module, right? What I would do is rename it to something that doesn't say "chrome" first, then we can add it to GNOME JHBuild and include it in our platform releases to encourage distros to pick it up. Does that sound good? It does make sense for it to be packaged by distros, right?
> I don't think it can use WebExtensions as that'd be a big project that > nobody seems to be interested in working on I see. From that point of view NPAPI plugin indeed can not be dropped now. > but it should be relatively straightforward to throw together some JS API > that's only made available to extensions.gnome.org if you want to drop the > plugin For now (while I can support both async and sync sweettooth APIs at e.g.o.) I do not have a goal to kill NPAPI plugin. However if it (dropping NPAPI part) will help to enhance GNOME Web itself I would be glad to help. Async JS API is ready [1] btw (my bad - it's not documented now). You should already know sync version (NPAPI). Async version return Promises instead of real values for all functions and have "initialize" function to setup all properties. > We do still need to get chrome-gnome-shell into distros, but I don't see any > particular reason to include it in the gnome-shell codebase; it can live happily > as a separate module, right? The reason is same as with NPAPI plugin - every GNOME user should be able to install GNOME Shell extensions with minimal efforts. I (as well as some distros maintainers [2][3] and users [4]) think that it should be a part of GNOME Shell. [1] https://git.gnome.org/browse/chrome-gnome-shell/tree/extension/include/sweettooth-api.js#n29 [2] https://github.com/gentoo/gentoo/pull/849#issuecomment-185443161 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849348 [4] https://bugzilla.mozilla.org/show_bug.cgi?id=1325827#c11
(In reply to Yuri Konotopov from comment #10) > For now (while I can support both async and sync sweettooth APIs at e.g.o.) > I do not have a goal to kill NPAPI plugin. > However if it (dropping NPAPI part) will help to enhance GNOME Web itself I > would be glad to help. Not really, the NPAPI code lives in WebKit and we have to keep and support it regardless. I just wanted to disable it in Epiphany because that's what all the trendy browsers are doing and it makes it feel more modern. But apparently people still want to use NPAPI. :P > The reason is same as with NPAPI plugin - every GNOME user should be able to > install GNOME Shell extensions with minimal efforts. > I (as well as some distros maintainers [2][3] and users [4]) think that it > should be a part of GNOME Shell. But it can be installed by default in distros without becoming part of the gnome-shell codebase, so you have separate git histories. I guess it could become a submodule in the same way that gnome-shell-sass is, though. Anyway, that's not up to me as I'm not a gnome-shell maintainer; I would file another bug report to track this.
Now when visiting extensions.gnome.org see this error: "We cannot detect a running copy of GNOME on this system, so some parts of the interface may be disabled. See our troubleshooting entry for more information." Did we drop support for this browser plugin?
(In reply to Michael Catanzaro from comment #12) > Did we drop support for this browser plugin? I did not touch e.g.o. part of integration. It *almost* works for me in GNOME Web 3.20. However I see random errors with it (I saw them all time as I remember). In Firefox it works without issues for me.
Maybe if it still doesn't work reliably, we should just remove the browser plugin. Consider filing an epiphany bug to implement the subset of WebExtension APIs you need for this extension, it'll be a good starting point for us.
Finally Epiphany 3.30 has disabled support for NPAPI plugins. So this plugin no longer works in Firefox, Chrome, or Epiphany (unless you toggle a hidden setting that users won't know about). Surely it's time to remove it.
(In reply to Michael Catanzaro from comment #15) > Surely it's time to remove it. Fine with me after branching, but I don't think it's an appropriate change for 3.30.1.
Frustrating that this hasn't been migrated to GitLab... OK here goes
Ah the GitLab doesn't actually have any CI anyway, so wouldn't matter anyway. I'm going to push this blind because I'm too lazy to build the new mutter API version. If it breaks then I deserve to be yelled at (but you should really set up CI, so it'd at least be possible to check if it builds remotely).
Created attachment 374177 [details] [review] Remove the browser plugin
(In reply to Michael Catanzaro from comment #18) > but you should really set up CI, so it'd at least be possible to check if > it builds remotely). Yes, but it's tricky. We often require mutter master, and for some merge requests even non-master branches from corresponding mutter merge requests.