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

John Bieling john.bieling at gmx.de
Thu Oct 17 08:06:16 UTC 2019


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?

https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Content_scripts

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 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
>
> _______________________________________________
> 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/fa322293/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/fa322293/attachment-0001.png>


More information about the tb-planning mailing list