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 :)
> 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.
>
> 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.
> 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.
> - 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 :)
>
> - 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.
>
> - 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" ;)
--
Giorgio Maone
https://maone.net
_______________________________________________
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to
tails-dev-unsubscr...@boum.org.
