Dropping legacy support: Moving forward
mbanner at mozilla.com
Thu Oct 10 11:56:41 UTC 2019
On 07/10/2019 23:03, Magnus Melin wrote:
> On 06-10-2019 12:33, John Bieling wrote:
>> We are in this situation, because Firefox/Mozilla decided, that
>> WebExt is the new thing. If Firefox would not have done that, we
>> would be still be able to create powerful add-ons, which can do
>> almost everything. There has never been a security issue with
>> Thunderbird extensions. The reason Firefox closed WebExt Experiments,
>> are security issues, I think.
Please can you give your citation to back up that there's "never been a
security issue with Thunderbird extensions"? Have you checked all the
security reports that Thunderbird's ever had? Have you checked that
every single extension has never loaded a message in a chrome context or
handled unsanitized code?
We might not know about it, but it might still have happened. Generally
I've always had the impression that because of the smallish user base,
Thunderbird's never really been a significant target for hackers, but
that's speculation, and we don't know if there's targeted efforts
happening that don't get reported to us.
> There is a security issue with current style add-ons: They can do
> anything per design - but that's not a desired design related to
I'd like to expand on Magnus' comments here with my own understandings
of what was causing the change (these are not always first-hand
observations, but what I've come to understand over the years, so the
actual reasons may be slightly different, but I think these still fit well).
For Firefox, it wasn't just about security. There were lots of things,
to name a few: extensions causing Firefox to be unusable on startup
after an upgrade or at other times because we'd changed the backend
code, theming issues, causing crashes, two add-ons interacting badly...
as well as being able to introduce security issues by displaying items
in the wrong context, or altering behaviour badly etc etc. Another
example is that extensions could actually break Firefox's upgrade
process, because they could change anything...
Added onto this, due to the number of add-ons and their combinations,
you simply couldn't just test your way out of it.
All of that was ending up with a bad experience for users, and they
would generally blame Firefox. You'd also get the extension authors
complaining about the amount of changes, and having to keep up.
So what do you do? Simplify the API with a firm decision to support it
as much as possible (which stops the user facing issues) and as a result
give the add-on authors a route where they aren't going to have to do
changes every version.
Thunderbird may not be having such significant issues all the time, but
it is happening, and regardless the risks are there.
>> I can understand, that we need to follow the WebExt path, but
>> disabling WebExt Experiments is your own choice, right? If WebExt
>> Experiments do allow us to do all the things we need, why are we not
>> allowed to use them (later)?
I think at some stage, this all access pass does need to go away, for
the reasons above, and to make everyone's life simpler and more
reliable. You're complaining about these big backend changes, dropping
xul etc, but you're also complaining that you now won't get as much
access. The big changes aren't going to be stopping any time soon...
With my add-on author hat firmly on, yes it might be a shame for there
to be less access, but I also see this as an opportunity to help shape
the MailExtension API and Thunderbird. For example, Thunderbird
Conversations completely changes the message preview view - without
privileged access replacing that might be hard. However, I'm starting to
think about what does Conversations really need to access from
Thunderbird? What sort of API would fulfil that? How could some of the
message display functionality be replaced in a useful way for
WebExtensions, that doesn't potentially break everything like it does
currently (yes, the monkey patching is scary).
>> I think this question must be answered now, as I do not want to go
>> through this in 5 years, when my addons again stop working, because
>> WebExt Experiments will be disabled.
> To put this in perspective: converting your bootstrapped add-on to an
> experiment should not be terribly hard or much work. The work you'd
> put into maintaining that add-on over 5 years is by my guess quite
I haven't tried this yet, as I'm in the middle of a big rewrite that's
mainly be caused for other reasons, but I'm mainly expecting that to
convert from 'legacy' to WebExt experiments based, I could probably just
move my functions from bootstrap.js into some calls behind an experiment.
The hardest bit might be the startup/shutdown functions, although I'd be
tempted to see if they're really needed now - as in, do you just need to
cause a module to be loaded? Could that be done from a background script?
They could probably be replaced by the runtime.on* events that the API
provides, so worst case I could channel those through a simple
experiment API, and have that do what bootstrap used to do.
Overall, that would be fairly simple, I doubt it'd take too long, and
it'd give a good introduction to how experiments work, that you could
then translate everything across.
On conversations, I've already started migrating the preferences
from Thunderbird's preferences system to the storage system, using an
experiment API. It enabled me to also get the button for preferences
back on the add-ons page. Once that's been out for a while, I'll likely
drop reading/saving the preferences on the Thunderbird side completely.
This only took me an hour or two to figure out.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tb-planning