Proposal: MailExtensions API to allow UI overlays, but no script injection
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
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