Proposal: MailExtensions API to allow UI overlays, but no script injection - what happens to "chrome" ?

Axel Grude axel.grude at
Wed Oct 16 12:36:41 UTC 2019

>>>> *2. Overlay is a security issue*
>>>> We simply disallow any JS and ignore any JS when parsing the overlay file. There 
>>>> is no security issue. After removing all the JS script stuff, the API will 
>>>> probably be even shorter than 500 lines.
>>> If no js is running, how would you for example insert a button to click on?
>> The idea was to have an event fired after a registered overlay has been injected 
>> into a window, which the api user can subscribe to. Here my knowledge about WebExt 
>> is still to limited to outline this further, but maybe the event returns an object 
>> with "id: element" members of the added elements and we can then do something with 
>> them, like adding event handlers to execute JS functions available in the webExt 
>> context. That would also seperate UI and logic.
> This might be an area to look in to more then. As soon as you have one element of a 
> dom tree, you have full access to the dom. For example, 
> element.appendChild(element.ownerDocument.createElement("script")).  Or 
> element.ownerDocument.querySelector("img").setAttribute("onerror", "evil()")
> Therefore, if you want interactive elements then you'll likely end up with a 
> declarative API.
> I'm also not sure you can pass DOM nodes around in WebExtension APIs, they are meant 
> to work across process boundaries and passing raw nodes would likely also break the 
> upcoming site isolation.

what about the "chrome context" is that  going away completely?

There is an awful lot talk about *sites */ content tabs / the browser etc. which I 
feel isn't really relevant to mail. This is all so Firefox / browser centric.

Does mail live in a "site context"? Would it be "one site per mail server / account"? 
Would then something like moving mails from one account to another be prohibited?

What about instant messages?

My view is that the downloaded mails are not living in a site context anymore, they 
belong to the user; same when composing an email. That's where the really useful 
Add-ons work in my perspective. Thunderbird is not a web browser. :)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the tb-planning mailing list