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

alta88 alta88 at fixall.com
Sat Oct 12 00:41:54 UTC 2019



On 10/11/2019 04:55 PM, Geoff Lankow wrote:
> On 12/10/2019 11:20, Eyal Rozenberg wrote:
>> On 12/10/2019 1:08, Geoff Lankow wrote:
>>> but having the ability to change any window and do anything to it 
>>> /can not/ and /should not/ continue.
>>
>> Why? That is a keystone feature of Thunderbird's - the fact that UI 
>> from an extension code is basically on equal footing with in-app UI.
>>
>>
> I made my case. It simply is not feasible any more. We barely have 
> enough developer time to do important things that benefit all users, 
> let alone maintain such a sprawling monster for a small fraction of 
> users. Saying "just keep it" is easy. Just keeping it is anything but. 
> Trust me, I've spent a large chunk of the last 15 months trying to 
> "just keep it".

That ('not feasible') just isn't true. It isn't necessary to have xul 
loaders and overlays, and it is completely correct that chrome.manifest 
and everything in it must go. That does _not_ mean no access by 
extensions to chrome UI and it doesn't even mean some sort of access 
point api.

In Bug 1579066 there is a proposed chrome-WE messaging mechanism. Along 
with the example of 2 medium complex extensions which are 
chrome.manifest free, yet retain all prior functionality from when they 
were overlay extensions. All it took was 3 tiny experiment functions and 
a lot less than even 1 month.

It's disappointing that there is no strategy for how to move into the WE 
world and retain functionality. What we have is abrupt announcements 
pulling support in the absence of being able to figure out a strategy, 
because that "is easy".




More information about the tb-planning mailing list