After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 766776 - Kill browser plugin
Kill browser plugin
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: general
3.21.x
Other Linux
: Normal enhancement
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
: 729452 (view as bug list)
Depends on: 777623
Blocks:
 
 
Reported: 2016-05-22 16:02 UTC by Michael Catanzaro
Modified: 2019-01-09 17:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Remove the browser plugin (98.33 KB, patch)
2016-05-22 16:09 UTC, Michael Catanzaro
committed Details | Review
Remove the browser plugin (98.54 KB, patch)
2018-12-31 19:31 UTC, Michael Catanzaro
committed Details | Review

Description Michael Catanzaro 2016-05-22 16:02:45 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.
Comment 1 Michael Catanzaro 2016-05-22 16:09:08 UTC
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.
Comment 2 Michael Catanzaro 2016-05-22 16:11:45 UTC
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.
Comment 3 Florian Müllner 2016-05-22 16:27:32 UTC
(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 ...
Comment 4 Florian Müllner 2016-07-11 20:20:20 UTC
*** Bug 729452 has been marked as a duplicate of this bug. ***
Comment 5 Michael Catanzaro 2016-10-26 17:46:21 UTC
Note that support for browser plugins has been removed from Epiphany 3.23.1.
Comment 6 Michael Catanzaro 2016-10-28 01:10:49 UTC
(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.
Comment 7 Yuri Konotopov 2016-12-27 09:44:07 UTC
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
Comment 8 Yuri Konotopov 2016-12-27 09:59:59 UTC
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
Comment 9 Michael Catanzaro 2016-12-27 15:41:00 UTC
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?
Comment 10 Yuri Konotopov 2016-12-27 20:32:06 UTC
> 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
Comment 11 Michael Catanzaro 2016-12-27 22:08:40 UTC
(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.
Comment 12 Michael Catanzaro 2017-01-22 15:01:44 UTC
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?
Comment 13 Yuri Konotopov 2017-01-22 18:34:47 UTC
(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.
Comment 14 Michael Catanzaro 2017-01-22 20:54:23 UTC
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.
Comment 15 Michael Catanzaro 2018-09-11 19:13:40 UTC
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.
Comment 16 Florian Müllner 2018-09-11 21:19:40 UTC
(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.
Comment 17 Michael Catanzaro 2018-12-31 19:22:50 UTC
Frustrating that this hasn't been migrated to GitLab... OK here goes
Comment 18 Michael Catanzaro 2018-12-31 19:31:27 UTC
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).
Comment 19 Michael Catanzaro 2018-12-31 19:31:57 UTC
Created attachment 374177 [details] [review]
Remove the browser plugin
Comment 20 Florian Müllner 2019-01-09 17:47:08 UTC
(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.