GNOME Bugzilla – Bug 727936
Integration plugin does not work with Chrome M35
Last modified: 2017-01-02 18:46:20 UTC
As of Chrome version 35 (to be released to the stable channel in May), NPAPI browser plugins will no longer be supported.[1][2] It is therefore not possible in these versions of Chrome to install/update/remove extensions using extensions.gnome.org. Currently, the gnome shell integration plugin is not loaded in google-chrome-unstable (35.0.1916.17 (Official Build 261600) dev aura), according to about:plugins . When Chrome M35 is released to stable, extensions.gnome.org will no longer be functional in any Chrome browser. [1] https://groups.google.com/a/chromium.org/forum/#!msg/chromium-dev/xEbgvWE7wMk/D_07G2lftacJ [2] http://blog.chromium.org/2013/09/saying-goodbye-to-our-old-friend-npapi.html
Ok, so what should we do? Reimplement the plugin using the new API? Is that documented somewhere, and how different is it than NPAPI? Does it support scripting in the same way (get the embed DOM node, call JS functions on it)? Btw, other browsers support NPAPI just fine, and they don't implement the Chrome one. It would be a shame to have two browser plugins.
The new API that Chrome is pushing forward is PPAPI.[1] I have no experience with either API, so I can't tell you exactly how it is different from NPAPI, but the documentation [2][3] should be a good start in figuring out what is possible. Some articles[4] seem to suggest that Firefox will be moving away from NPAPI plugins in the (near) future as well. Firefox seems to be pushing js-ctypes as an alternative. Looking at this [5] website, there are a few other alternatives. I'd guess that WebSockets might be a possibility for the extensions.gnome.org website, since it will be supported by all major browsers. [1] https://code.google.com/p/ppapi/ [2] https://code.google.com/p/ppapi/wiki/GettingStarted [3] https://code.google.com/p/ppapi/wiki/InterfacingWithJavaScript [4] http://stackoverflow.com/questions/19011884/chrome-and-firefox-are-not-going-to-support-npapi-for-long-what-are-my-options [5] http://www.firebreath.org/display/documentation/Browser+Plugins+in+a+post-NPAPI+world
*** Bug 728001 has been marked as a duplicate of this bug. ***
A suggestion to skip the need for two interfaces, NPAPI and PPAPI. What about a small local webserver with some nice rest-interface to communicate with gnome-shell. This way most network tools and libraries can use it natively (for example, curl -H "Accept: application/json").
BTW, Chromium dropped Linux NPAPI support a while ago; matter of fact they dropped it in September of last year, with the new rendering engine Aura. The rationale was that adding support only to use for a few months was pointless. Windows and Mac are going to see their short default NPAPI whitelist gone this month, assuming it hasn't hit already. The plan is for Chrome/Chromium to have 0 support by September of this year, with existing ones being removed by April. Here's an official guide for Chrome's NPAPI deprecation policy: http://www.chromium.org/developers/npapi-deprecation Chrome still has the Native Client interface for binary applications, and they are handled not that differently than regular JS extensions, but Mozilla prefers for people to use their js-ctypes interface in addons. Chrome also has the capability to run transparent addons as well. I can't find much explicitly from Mozilla about their deprecation plan, but they clearly are trying to get people to stop using it. I wish they were a little more clear and blunt like Chrome, so more people would be aware of it. They currently require click-to-play to run NPAPI plugins. Chrome has a few ways to check native specifics, but Mozilla has more of such amenities. Also, AFAIK, both have ways for checking for existence of addons/extensions in some form or another.
At a minimum, the https://extensions.gnome.org/about/#no-detection page should include the information that the site is broken for chrome. Currently it lists steps that won't work for chrome and doesn't use browser names to distinguish which ones might have problems.
Ping...Chrome has a larger share than Firefox, and I believe that carries over to Linux as well.
(In reply to Martin Insulander from comment #4) > A suggestion to skip the need for two interfaces, NPAPI and PPAPI. My suspicion is that this is impossible to do with PPAPI anyways, since plugins are most likely running sandboxed. > What about a small local webserver with some nice rest-interface to > communicate with gnome-shell. This way most network tools and libraries can > use it natively (for example, curl -H "Accept: application/json"). Yes, a local webserver is likely the best way to handle it. The difficulty is security - how do you know that a request to the web server is explicitly triggered by the same user from the same account? There are inherent limitations in the D-Bus API that help (in particular, you can only trigger a download of an extension from extensions.gnome.org, not from any arbitrary URL), but other users on the same machine should still not be able to fool with the users extension settings. On Linux, it is roughly possible to track down the other half of a TCP connection to localhost - a system service can check that the peer socket is owned by a process running within a local session and forward the request back to that session. CORS (http://en.wikipedia.org/wiki/Cross-origin_resource_sharing) can be used so that the local web service can only be accessed by https://extensions.gnome.org and not arbitrary sites on the internet. websockets might be useful to avoid having to validate the peer for each API request separately. (In reply to impinball from comment #7) > Ping...Chrome has a larger share than Firefox, and I believe that carries > over to Linux as well. It's a largish project, but if you are interested, I'd be happy to provide more detailed guidance!
Maybe it's time to push extension management in Gnome Software.
BTW, the problem still persists in M42 Beta. (In reply to Clément Guérin from comment #9) > Maybe it's time to push extension management in Gnome Software. Agreed. (In reply to Owen Taylor from comment #8) > (In reply to impinball from comment #7) > > Ping...Chrome has a larger share than Firefox, and I believe that carries > > over to Linux as well. > > It's a largish project, but if you are interested, I'd be happy to provide > more detailed guidance! I would love to help, but I'm not familiar enough with PPAPI or Chrome extension APIs to be able to fix this anytime soon. Sorry about that. (I'm mostly focused with JavaScript development, particularly Node.js.)
*** Bug 746899 has been marked as a duplicate of this bug. ***
Confirmed: Firefox dropping NPAPI plugins by the end of 2016 except for Flash http://arstechnica.com/information-technology/2015/10/firefox-dropping-npapi-plugins-by-the-end-of-2016except-for-flash/
Original mozilla blog post here: https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/
Created attachment 318212 [details] Chromium extension prototype Hello. I'm investigated capabilities of Chrome extensions and created a prototype that just enumerate installed plugins at extensions.gnome.org. Prototype contains of chrome extension and native python messaging host (https://developer.chrome.com/extensions/nativeMessaging) that communicate with dbus. I will publish sources in a day or two after implementing all SweetTooth api methods (although i will upload it to somewhere early if someone will be interested).
I just published source code of extension and native connector at https://github.com/nE0sIghT/chrome-gnome-shell and packed extension at Chrome store (https://chrome.google.com/webstore/detail/gnome-shell-integration-f/gphhapmejobijbbhgpjhcjognlahblep) Implemented parts: 1. Listing of installed extensions 2. Enabling/disabling 3. Configuration of extensions
All parts of API implemented and works for me. For now only "onshellrestart" callback disabled in extension since i have some strage issues with Chrome native messaging and that callback.
@nE0sIghT, just tested your extension. Everything works. Thank you very much!
I added cmake build script and Gentoo ebuild to vortex overlay. In Gentoo it is possible to install native connector with commands: layman -a vortex emerge gnome-extra/gs-chrome-connector
(In reply to nE0sIghT from comment #15) > I just published source code of extension and native connector at > https://github.com/nE0sIghT/chrome-gnome-shell and packed extension at > Chrome store > (https://chrome.google.com/webstore/detail/gnome-shell-integration-f/ > gphhapmejobijbbhgpjhcjognlahblep) > > Implemented parts: > 1. Listing of installed extensions > 2. Enabling/disabling > 3. Configuration of extensions Thanks!!! (In reply to nE0sIghT from comment #18) > I added cmake build script and Gentoo ebuild to vortex overlay. > In Gentoo it is possible to install native connector with commands: > > layman -a vortex > emerge gnome-extra/gs-chrome-connector Double thanks!!!
(In reply to nE0sIghT from comment #16) > For now only "onshellrestart" callback disabled in extension since i have > some strage issues with Chrome native messaging and that callback. I reenabled "onshellrestart" callback so all API properties works now.
With latest changes to cmake script there is no need to install extension manually from Chrome web store: https://github.com/nE0sIghT/chrome-gnome-shell/commit/a4426cea24be1a8d764705a275b16a39fecc70e6 2 preferences files are installed (for Chrome and Chromium) so browser will install extension from Chrome web store at next start.
Is it possible getting your plugin working in Opera? Or do you know of any APIs missing?
(In reply to Odin Hørthe Omdal from comment #22) > Is it possible getting your plugin working in Opera? Or do you know of any > APIs missing? Missing non critical: chrome.notifications.TemplateType.LIST chrome.storage.sync Missing critical: Native host messaging manifest location for Linux not documented: https://dev.opera.com/extensions/message-passing/#native-messaging External extension distribution possibility unknown.
Hi everyone. Since the time of last update GNOME Shell integration for Chrome was moved to GNOME infrastructure. Wiki page: https://wiki.gnome.org/Projects/GnomeShellIntegrationForChrome I think this bug can be closed now.
(In reply to Odin Hørthe Omdal from comment #22) > Is it possible getting your plugin working in Opera? Or do you know of any > APIs missing? Opera support was recently added to chrome-gnome-shell master branch and will be available in version 7. Extension is now on moderation in Opera Addons site. For now you can manually load extension (cloned from git master branch) to Opera browser using Developer mode in Extensions page.
(In reply to Odin Hørthe Omdal from comment #22) > Is it possible getting your plugin working in Opera? Or do you know of any > APIs missing? Version 7 with Opera support is available. https://wiki.gnome.org/Projects/GnomeShellIntegrationForChrome/ReleaseNotes/7 https://addons.opera.com/extensions/details/gnome-shell-integration/
*** Bug 738754 has been marked as a duplicate of this bug. ***
Implemented in GNOME Shell integration for Chrome [1]. Closing fixed. [1] https://wiki.gnome.org/Projects/GnomeShellIntegrationForChrome