Giorgio Maone:
> On 28/08/2015 17:37, sajolida wrote:
>> In terms of extension code, Maone told us he would be busy with other
>> extension work over the summer but maybe he's back on track now. Giorgio
>> what's up? Do you have any ETA for a first prototype? Anything blocking you?
>
> The main roadblock was Mozilla finalizing its add-ons migration strategy
> to the Electrolysis (e10s) multi-process & sandboxing architecture.
> Without an ultimate public decision, which has been deemed "imminent"
> for all the past month (see
> https://labs.riseup.net/code/issues/8567#note-7 ), it was hard to even
> decide which of the 4 different technical approaches to develop Firefox
> add-ons was the best for this project:
>
> 1. XUL/XPCOM, like desktop NoScript;
> 2. restartless, like Android NoScript;
> 3. Add-on SDK;
If I understodd correctly, these were the three options that were
already available previously.
> 4. WebExtensions, the new, future proof, Chromium-like thing (not even
> disclosed yet until last week, but I was aware of it earlier because
> I've been working closely with the e10s/add-ons team)
This move to WebExtensions indeed sounds interesting from a portability
point of view.
> This finally happened last week, with this announcement:
> https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/
Read.
> More about WebExtensions:
> https://wiki.mozilla.org/WebExtensions/
> https://wiki.mozilla.org/WebExtensions/FAQ
>
> As I told intrigeri when we met, I had really hoped to develop our
> extension with the new API to improve its longevity and make a Chrome
> porting easy to do and maintain, but unfortunately, as you can also
> deduce from the links above, the decision have been dragged for so long
> that we wouldn't be able to support the Tor Browser (based on ESR) for
> about one year.
Ok.
> Furthermore, until my own native.js proposal (
> https://discourse.mozilla-community.org/t/proposal-native-js-to-embrace-extend-the-webextensions-api/3457
> ) gets implemented (
> https://bugzilla.mozilla.org/show_bug.cgi?id=1199718 -- filed just
> minutes ago), the WebExtensions API is not powerful enough to support
> our requirements.
Ok.
So the dilemma we're facing here is to find the proper technology to use
in order to be compatible with Electrolysis (FF43) while not being able
to write it in WebExtensions (no ETA). Sounds like a pretty bad time to
start writing new Firefox extensions :)
> Therefore the only currently available option ensuring longevity is the
> Add-ons SDK (AKA "Jetpack").
I'm probably lacking technical background to understand what leads us to
this conclusion and what are its implications, especially regarding the
UX we envisioned.
I understand that Firefox wants to deprecate XUL/XPCOM, so we're left
with option 2. restartless, and 3. Add-on SDK. But how do you choose
Add-on SDK from these two:
- Do you need to restart the browser after installing a Add-on SDK
extension? If so, then we probably need to rethink our wireframe,
rethink what happens in browser with no history like Tor Browser, etc.
- What's the problem with restartless extensions? Will they become
deprecated? Do they rely on XUL? Are they not e10s ready? Would they be
much harder to port to WebExtensions?
- What's currently the recommended technology to start developing e10s
ready extensions that don't require restarting the browser? None?
If I understand correctly, it will make a lot of sense to port our
extension to WebExtensions anyway once it's available in Tor Browser and
developed enough, maybe in a joint effort to have the extension ported
to Chrome. That could be in one year or more. So was longevity your only
criteria to go for Add-on SDK?
> I've just received guarantees from Mozilla (in a meeting held today)
> that they will give us any assistance for our extensions to be supported
> by any of the foreseeable future Firefox versions.
>
> I've already set up a development environment and started hacking. I'm
> gonna commit something to the git repository next week, and a working
> prototype most likely by the end of September.
>
>> Just to let you know, we want to do extensive user testing sessions of
>> the whole process (Installation Assistant + Verification Extension) in
>> November. So we need all the pieces to be ready by then.
>
> I'm confident it's going to happen timely.
Nice!
