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

Magnus Melin mkmelin+mozilla at iki.fi
Thu Oct 17 07:32:45 UTC 2019


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 gmail.com>*
> Music Production and Composition
> Thunderbird Add-ons Developer (QuickFolders 
> <https://addons.thunderbird.net/thunderbird/addon/quickfolders-tabbed-folders/>, 
> quickFilters 
> <https://addons.thunderbird.net/thunderbird/addon/quickfilters/>, 
> QuickPasswords 
> <https://addons.mozilla.org/firefox/addon/quickpasswords/>, Zombie 
> Keys <https://addons.thunderbird.net/thunderbird/addon/zombie-keys/>, 
> SmartTemplate⁴ 
> <https://addons.thunderbird.net/thunderbird/addon/smarttemplate4/>)
> Visit my YouTube Channel <https://www.youtube.com/c/thunderbirddaily> 
> for email productivity tips Get Thunderbird!
>> *Subject:*Re: Proposal: MailExtensions API to allow UI overlays, but 
>> no script injection
>> *From:*Eyal Rozenberg <eyalroz at technion.ac.il>
>> *To:*Thunderbird Planning (Moderated) <tb-planning at mozilla.org>; John 
>> Bieling <john.bieling at gmx.de>
>> *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 mozilla.org
>> https://mail.mozilla.org/listinfo/tb-planning
>> .
>
> _______________________________________________
> tb-planning mailing list
> tb-planning at mozilla.org
> https://mail.mozilla.org/listinfo/tb-planning
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20191017/80c14816/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: thunderbird_blog2.png
Type: image/png
Size: 846 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20191017/80c14816/attachment-0001.png>


More information about the tb-planning mailing list