GNOME Bugzilla – Bug 730029
Support WebExtensions
Last modified: 2018-08-03 20:18:48 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.
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.
I think we need to follow what firefox is doing. They will bring chrome extensions to firefox soon.
(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
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.
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?
(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
-- 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.