Extensions support (Chrome and Firefox)

[landroni]

I see that 'extensions' is on the TODO list. But I was curious whether Otter plans to support existing Chromium extenions? More specifically, will the Ghostery extension be available in Otter?

[Emdek]

All in good time, I plan to have support for existing extensions APIs (most interesting options are Firefox and Chrome), and try to avoid need to expose custom ones.

It might make sense to implement them also as modules, wrappers for core APIs, exposing them in a way expected by existing extensions.

[landroni]

Sounds like a nice plan.

PS Thanks a lot for working on this. I was initially skeptical, but the screenshots look very juicy indeed in recreating good old Opera 12. I only hope that you will reach stability faster than, say, Midori (which I also consider as a viable alternative to Chropera (aka Opera 15+).

[Emdek]

Midori is still is not enough mature?
When I've look some years ago it looked not that bad, there were few missing things still, but worked quite nicely.

[landroni]

Midori is nice, but has some glaring omissions: password manager, chromium extensions or similar, the dynamic 'new tab' button next to the right-most tab, etc. I like Midori for occasional browsing, but I never managed to settle with it for day-to-day browsing as I can with Opera 12.

[Emdek]

Ah, well, I guess that they intend to be more like thin wrapper around WebKit.

[lollox]

I think that support for FF extensions could be very very problematic... Most of them rely on XUL to create GUI elements and interaction and emulate this (if possible) could be also a resource eater process...

The chromium ones are more suitable since follow more strictly the "widget draft" developed by Opera years ago and rely for GUI only on HTML/JS technology... And even here there is the big problem of "proprietary" APIs that call directly features exposed by the chromum engine

[Emdek]

Well, full compatibility with Firefox extensions is impossible anyway, but as much as could be done - should be done. ;-)

[Piter432]

Will be a support for Opera 12 extensions also? :)

[Emdek]

@Piter432, if someone would like add support for them then it could be considered, but I don't believe that it would be useful, many extensions are ports from Firefox or could be easily (probably most of them if not all) ported to these architectures.

[Muzer]

Yeah, Firefox extension support sounds a bit too ambitious to me. What, are you going to have a layer emulating XUL? IMHO stick with more feasible things ;)

[Emdek]

@Muzer, AFAIK they have few different kinds of APIs, not all are bound to XUL. ;-)

[Emdek]

OK, we can't avoid it any-longer, we are starting on resolving task #42, the so called "Answer to the Ultimate Question of Life, the Universe, and Everything", at least in our context. ;-)

OK, now seriously, we will start small, by introducing concept of "scriptlets", small JS/ECMAScript snippets to replace custom buttons and partially bookmarklets using APIs compatible with Chrome, trying to implement next APIs one by one, until we will be able to start advertising support for full blown, existing extensions etc.
Each snippet will behave like actions right now, it will be possible to trigger it by shortcut, add to some menu or place as button on toolbar (although these two uses will require support for events which would allow to properly update their UI state, like icon or title).
There are still few loose ends left in our design, but it is already proven to be feasible (design process was started in December 2013, but without help from @Frenzie I would be stuck on deciding on some critical details).

[lollox]

With all the recent changes and news from Mozilla, I think finally it's the time to simply change the goal to "support the WebExtension platform" as all other browsers. (old Opera extensions are dead, Firefox XUL and SDK ones will be totally dropped this year)

Probably an easy task for the WebEngine backend... a bit more effort for the WebKit one?

[Emdek]

@lollox, old title still fits, that just means one set of APIs now. ;-)
At the moment it doesn't matter which backend would be used, both do not expose any helpers currently.

[zakius]

not exactly one set as they are alike yet completely different (especially that chrome extensions API doesn't support all the new ES features available for websites while WebExtensions take great use of them)
though I'd love to be able to use some (or exactly one at least) of my Firefox extensions

[Frenzie]

Which one? Curious minds want to know. :-P

[zakius]

Which extension? Long lost Pocket as it gives me full access to my list without loading that heavy webapp and performs search in local cache so it's blazing fast!

and if you are asking about which features are not exactly available for chromium extensions WebExtensions docs mentioned Promises for example (at least while interacting with built-in functions, might be available for everything else), though it could've changed already

[Frenzie]

I was asking about Promises (well, I didn't know that of course :-P). Odd/interesting that it wouldn't be available for extensions.

[zakius]

I assume it's more like while built in function in WebExtensions returns Promise analog function of Chrome Extension expects callback as a parameter, not that Promises are completely unavailable

[smnthermes]

Why not just rebase Otter Browser on Firefox or Chromium?

[Sa-Ja-Di]

@smnthermes Using basic Chromium or Firefox would mean Otter would lose all customization options it just has right now and would instead become another generic simple users browser.

There is enough generic ware around already... Most prominent examples: Opera and and Mozilla - Both sacrificed almost all customization features to offer "100% Chrome user compatibility"