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 730029 - Support WebExtensions
Support WebExtensions
Status: RESOLVED OBSOLETE
Product: epiphany
Classification: Core
Component: General
3.18.x (obsolete)
Other Linux
: Normal enhancement
: ---
Assigned To: Epiphany Maintainers
Epiphany Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-05-12 20:39 UTC by Georges Basile Stavracas Neto
Modified: 2018-08-03 20:18 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Georges Basile Stavracas Neto 2014-05-12 20:39:09 UTC
GNOME Web is getting better and better on every release. One thing is really neccessary though: extensions.

Extensions enable users to customize their experience according to their wishes and needs. Also, they'll attract new developers around to create new and custom functionality.

Personally, I think Web isn't the best browser out there yet because (and only because) the lack of extensions.
Comment 1 Michael Catanzaro 2015-10-04 14:15:35 UTC
The old extension model was problematic for several reasons. We should instead support WebExtensions, beginning with the subset of functionality supported by both Firefox and Chrome, so that we can get extensions not written for Epiphany to work.
Comment 2 Mostafa Shahverdy 2015-10-17 19:51:56 UTC
I think we need to follow what firefox is doing. They will bring chrome extensions to firefox soon.
Comment 3 Bastián Díaz 2015-10-17 19:56:05 UTC
(In reply to Mostafa Shahverdy from comment #2)
> I think we need to follow what firefox is doing. They will bring chrome
> extensions to firefox soon.

Mozilla is working on an implementation of web extension for Firefox, which gives rise to universal (or almost) extensions for web browsers.

See: 
https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/
https://hacks.mozilla.org/2015/09/lets_write_a_webextension/
https://wiki.mozilla.org/WebExtensions

For UX problem that can generate support extensions on Epiphany, I suggest you choose to similar UI used firefox classic theme (add-on bar) or this add-on for australis: https://addons.mozilla.org/es/firefox/addon/new-add-on-bar/

Cheers
Comment 4 Michael Catanzaro 2015-10-17 20:22:31 UTC
I should mention: just because we want to support the same API, doesn't mean we want to implement everything exactly the same as those browsers. We should be as compatible as possible, but we don't want an add-on bar at the bottom, nor do we want to allow extensions to add buttons to the title bar: that would conflict with our emphasis on clean and simple UI. (Just like we don't allow apps to put icons in the top bar of GNOME.) Extensions that try to do those things should wind up with an entry in the window menu instead.
Comment 5 Mostafa Shahverdy 2015-10-17 20:41:34 UTC
Some question comes to mind. 
Like how do we want to host public extensions? Do we need to review and sign them? Are we going to have a easy-to-port platform api or we would be able to run the very exact extension that runs on Chrome or Firefox?
Comment 6 Bastián Díaz 2015-10-17 21:03:47 UTC
(In reply to Michael Catanzaro from comment #4)
> I should mention: just because we want to support the same API, doesn't mean
> we want to implement everything exactly the same as those browsers. We
> should be as compatible as possible, but we don't want an add-on bar at the
> bottom

It was just a suggestion.
Considering that it is working on a new download manager, one addon-bar at the bottom allow to see the extensions, considering: a) the addon-bar would be hidden by default. b) An option in the window menu/shortcut would show/hide the bottom bar c) extensions usually display a notification when require attention.

I regret not having explained this way before.

>, nor do we want to allow extensions to add buttons to the title bar:
> that would conflict with our emphasis on clean and simple UI. (Just like we
> don't allow apps to put icons in the top bar of GNOME.)

I think the most important reason is that the status icons in the tray does not make sense, it is an obsolete implementation and has no coherence.

>Extensions that try
> to do those things should wind up with an entry in the window menu instead.

Sounds good.

Moreover, I do not think it's a good idea to accept and support all types of extensions. Some only create links to create webapps (Epiphany already does). I think a limited set of extensions must be supported, as some extensions that allow the use of connectionless services (google docs, Office Online, etc.) or services not found on Linux (hangouts, skype web ?, etc.).

Cheers
Comment 7 GNOME Infrastructure Team 2018-08-03 20:18:48 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/epiphany/issues/240.