Proposal: MailExtensions API to allow UI overlays, but no script injection

Magnus Melin mkmelin+mozilla at
Thu Oct 17 12:59:28 UTC 2019

Yes, you understood it correctly. We're not there yet though.


On 17-10-2019 11:06, John Bieling wrote:
> WOW, that would make such a big difference, as I believe WebExtensions 
> can alter/access DOM of content pages, right? Or did I misunderstood 
> the definition?
> <>
> That would mean, we can alter the UI again. Correct?
> John
> Am 17.10.2019 um 09:32 schrieb Magnus Melin:
>> In one way yes it could kind of work kind of like that I think, with 
>> a significant twist, and with some limitations, and only on the 
>> longer horizon.
>> It's not yet clear exactly what technical barriers there are (a bunch 
>> for sure, potentially less than one would think though), but... one 
>> step at a time. Currently the Thunderbird UI is living in chrome. 
>> Most of it would be better off running in content. What I mean is, 
>> the 3pane and what makes up the main UI should really just be *seen 
>> as* a very fat web application running in a browser tab. With XBL now 
>> gone, and UI moving over to from XUL to HTML (last release with XUL 
>> is probably the 78 release), it's getting more and more feasible.
>> With that in mind, what you would have is Thunderbird as the web page 
>> (internally, technically, so not really, but still), and as an add-on 
>> author you could interact with that page the same way WXs can 
>> interact with normal web content. This is basically what WXs are 
>> designed for so it fits in very well. The add-on would have the 
>> powers it needs (though no XPCOM), and the Thunderbird UI has the 
>> powers of a content page, interacting with a back-end through 
>> suitable means (either http or data put into web compatible local 
>> storage mechanisms by the back-end).
>>  -Magnus
>> On 16-10-2019 15:31, Axel Grude wrote:
>>> Eyal wrote:
>>>> Extensions should be able to do essentially everything. Certainly 
>>>> everything the TB's _*own UI*_ code can do. 
>>> (emphasis by me)
>>> That's essentially echoing what my thought was about "Thunderbird 
>>> eating it's own dog food", so let me re-iterate the question:
>>> *How would a Thunderbird developer re-design the API if they were 
>>> forced to use it in their own front-end (JavaScript) code?*
>>> This question may sound a little ridiculous at first glance, but it 
>>> is an interesting thought experiment, because it forces the Core 
>>> Developer to think about the restrictions proposed on us who want to 
>>> add *more functionality* and *improve existing functions*. If you 
>>> think about it our goals aren't vastly different to those from 
>>> thunderbird core.
>>> If the API is the "safe point" for the front end, then why not force 
>>> Thunderbird Core code through the same gate? Possible answers
>>>   * Core needs to do more than Add-ons
>>>       (which is partly true, but Add-ons add stuff that core didn't
>>>     think of and users still find useful, so it also goes the other way)
>>>   * Core code is vetted and Firefox does not review web extensions code
>>>       (so far we did manually review and vet the code for security
>>>     with the Add-on reviewers crew. Which mainly consists of other
>>>     developers. Whether this is a big problem going forward remains
>>>     debatable; AFAIK there was *one* documented security breach
>>>     caused by an ADd-on in Tb within the last 10 years, which is not
>>>     a bad statistic compared to OS like windows)
>>>   * Core Developer are Trusted, anyone can  develop Add-ons
>>>       (I think this a stronger argument; the question is whether it
>>>     would be possible to have specially vetted / trusted Add-on
>>>     developers and only allow them XPCOM access and  how to vet
>>>     these people - A strong committment to the user base and regular
>>>     maintenance, bug fixing etc. would be good markers to start
>>>     from. So far I assumed there wasn't such a big difference in the
>>>     development community, except that core devs could be financed
>>>     by the foundation, whereas addon devs had to organize
>>>     monetization themselves. Maybe that aspect needs to be solved at
>>>     the same time.)
>>> I would still be very interested in at least one of the core devs 
>>> going through this thought experiment, even if just to come to the 
>>> conclusion that it's impossible. It may be not? Or it may lead to a 
>>> completely different answer.
>>> Axel
>>> *Axel Grude <mailto:axel.grude at>*
>>> Music Production and Composition
>>> Thunderbird Add-ons Developer (QuickFolders 
>>> <>, 
>>> quickFilters 
>>> <>, 
>>> QuickPasswords 
>>> <>, Zombie 
>>> Keys 
>>> <>, 
>>> SmartTemplate⁴ 
>>> <>)
>>> Visit my YouTube Channel 
>>> <> for email productivity 
>>> tips Get Thunderbird!
>>>> *Subject:*Re: Proposal: MailExtensions API to allow UI overlays, 
>>>> but no script injection
>>>> *From:*Eyal Rozenberg <eyalroz at>
>>>> *To:*Thunderbird Planning (Moderated) <tb-planning at>; 
>>>> John Bieling <john.bieling at>
>>>> *Sent: *Saturday, 10/12/2019, 15:56 15:56 IST +0100 [Week 41]
>>>> Sorry for sounding like a broken record, but:
>>>> On 12/10/2019 9:25, John Bieling wrote:
>>>>> Why is it, extension should no longer be able to style the UI as 
>>>>> before? 
>>>> ... not just the UI. Extensions should be able to do essentially 
>>>> everything. Certainly everything the TB's own UI code can do.
>>>> Eyal
>>>> _______________________________________________
>>>> tb-planning mailing list
>>>> tb-planning at
>>>> .
>>> _______________________________________________
>>> tb-planning mailing list
>>> tb-planning at
>> _______________________________________________
>> tb-planning mailing list
>> tb-planning at
> _______________________________________________
> tb-planning mailing list
> tb-planning at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: thunderbird_blog2.png
Type: image/png
Size: 846 bytes
Desc: not available
URL: <>

More information about the tb-planning mailing list