Proposal: MailExtensions API to allow UI overlays, but no script injection
kewisch at thunderbird.net
Sat Oct 19 17:07:39 UTC 2019
Magnus' approach would definitely fit well in terms of providing access to content windows. It would however still allow script injection into Thunderbird UI, allow bypassing the permission system completely, allow developers to unintentionally break the Thunderbird UI, and make it difficult to change the UI without breaking add-on compat, and possibly some of the other downsides I mentioned. I'd love to hear how this would be mitigated.
I'm not sure how we can resolve this thread in a satisfactory way, I'd really like to. There are certainly downsides to my suggestions as well, so it is really a matter of weighing the risks and deciding which aspects are more important.
What might work is for now, is for you to use your overlays in an experiment, identifying use cases for more specific APIs along the way.
When Thunderbird UI is mostly in content, we can re-evaluate how to proceed with what level of access we'd give to extension developers. By this time we'll be in a completely different situation, have more apis, and it is possible they'd cover the majority of use cases.
Would this be acceptable?
> On 17. Oct 2019, at 2:59 PM, Magnus Melin <mkmelin+mozilla at iki.fi> wrote:
> 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?
>> 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).
>>> 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:
>>>> 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 Grude
>>>> Music Production and Composition
>>>> Thunderbird Add-ons Developer (QuickFolders, quickFilters, QuickPasswords, Zombie Keys, SmartTemplate⁴)
>>>> Visit my YouTube Channel for email productivity tips
>>>>> 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.
>>>>> tb-planning mailing list
>>>>> tb-planning at mozilla.org
>>>> tb-planning mailing list
>>>> tb-planning at mozilla.org
>>> tb-planning mailing list
>>> tb-planning at mozilla.org
>> tb-planning mailing list
>> tb-planning at mozilla.org
> tb-planning mailing list
> tb-planning at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tb-planning