Giorgio Maone:
> On 31/08/2015 20:55, sajolida wrote:
>> Giorgio Maone:
>>
>>> 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;
>
> First of all, let me clear what seems to be a qui pro quo I've
> involuntarily induced: I wrote "restartless add-ons" because that's
> their most commonly used name, but in this context I would better have
> used the "bootstrapped add-ons" designation, in orde to prevent the
> false impression that Add-on SDK extensions are not restartless themselves.
>
> Please notice that *Add-on SDK extensions are restartless add-ons*: the
> difference between #2 (bootstrapped) and #3 (SDK) is just the API
> they've got available, i.e. just bare XPCOM for #2 and a pure-JS
> sandboxed abstraction for #3.
>
> Only #1 (XUL/XPCOM legacy add-ons) require a browser restart after
> installation.
> As far as I understand, this should already wipe off most of the worries
> you expressed about the Add-on SDK :)
That's what I imagined :) *Big relief*
>> If I understodd correctly, these were the three options that were
>> already available previously.
>
> Indeed. During the past few months I've been involved in Mozilla's
> e10s/add-ons team, so I've been aware early that all these options were
> going to be deprecated sooner or later, hence my decision to defer any
> implementation commitment, but an actual schedule and details about the
> ultimate replacement have been missing until mid-August, mostly because
> a migration strategy for existing add-ons required careful planning and
> long discussions, both technical and "political". Even now, the
> situation is still in development.
Now I understand better your position. Thank you for taking the time to
mature this decision.
>> This move to WebExtensions indeed sounds interesting from a portability
>> point of view.
>
> Yes it does, even though there won't be a 1:1 mapping between the APIs,
> but more like a "shared core" intersection plus browser-dependent
> customizations reflecting the peculiarities of each browser and the
> expectations of its own user base (e.g. Mozilla will neglect those APIs
> whose main purpose is integrating with Google service, while is
> committed to make the features needed by the most popular current
> extensions available "natively" on the long run).
> Also, different browsers are going to use different formats and signing
> protocols, therefore cross-browser development will require at least
> some repackaging step.
Yes, that's how I understood it.
>> 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 :)
>
> That's the biggest elephant in the room at this moment, indeed,
> especially if you've got ESR compatibility as a requirement :(
> Things should get more exciting (very exciting, I believe) as soon as
> both the WebExtensions API and its native.js mechanism are supported in
> all stable Firefox versions, which unfortunately seems to be about one
> year away.
>
>> 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:
>
> Simple: non-SDK bootstrapped (restartless) add-ons can work without XUL,
> but still depend on XPCOM heavily, therefore they're not gonna outlive
> the XUL ones.
>
> Add-on SDK extensions are basically restartless add-ons themselves, but
> they run in a sandbox providing them with a rich high-level API
> available as CommonJS modules, and under certain constraints (i.e. not
> using XPCOM "super powers" which are currently available but are gonna
> be deprecated as well) are automatically compatible with Electrolysis,
> while bootstrapped ones require a considerable additional effort to
> achieve the same compatibility.
> In fact, the announcement states that Add-on SDK extensions will be
> supported for the foreseeable future as long as they don't call
> require('chrome'), i.e. as long as they don't touch XPCOM directly.
There's another fact that I didn't get initially: Add-on SDK are
automatically compatible with Electrolysis. Everything is clear now!
>> - 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.
>
> Fortunately that's not the case, since Add-on SDK extensions are
> themselves restartless :)
Thanks for the confirmation.
>> - 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?
>
> All the above, as I already explained, except probably the portability,
> which won't be a cakewalk in either case.
> However coding with portability in mind is obviously easier now than two
> weeks ago, which WebExtensions were not a public, finalized strategy.
And I guess it's also easier with Add-on SDK than any other technology.
>> - What's currently the recommended technology to start developing e10s
>> ready extensions that don't require restarting the browser?
>
> "If you're planning to write a new, Firefox-specific extension, the
> add-on SDK (Jetpack) may be your best option until WebExtensions matures".
> https://wiki.mozilla.org/WebExtensions/FAQ#I.27m_writing_a_new_extension_today._What_API_should_I_use.3F
>
>> 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 hope it's crystal clear now that the criterion was pretty much "only
> sane option currently available" ;)
Crystal clear, indeed.
I summarized all this on the blueprint for the record:
https://tails.boum.org/blueprint/bootstrapping/extension/#technology
