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

John Bieling john.bieling at
Sat Oct 12 20:03:24 UTC 2019

Am 12.10.2019 um 20:39 schrieb Philipp Kewisch:
>> On 12. Oct 2019, at 5:40 PM, John Bieling <john.bieling at> wrote:
>> Now before the thread derails, I would like to sum up. I think I
>> invalidated all arguments raised so far:
>> *1. Overlay is a code monster*
>> No its not, you can have a sleek implementation of about 500 lines
>> and no other place in the code base needs to know about the overlay
>> API. It is a self contained API. We will of course not use
>> chrome.manifest anymore.
>> The overlay API just needs the window listener and an xml parser.
>> There is actually not a big difference between XUL and HTML elements
>> in the overlay file, just the namespace is different when creating
>> the elements.
> I'll let Geoff make the argument. I think it was less about the LOC,
> but more about all the edge cases and things being expected to work.
I would go for simplicity here. No parent-matching or how that feature
might be called. A simple "add this before/after this ID-Element" or
"append to this ID-Element". These 3 types are for example the only ones
supported by my own OverlayManager (appendto="id", insertbefore="id",

>> *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.

> How would you prevent extensions from removing UI elements that belong
> to security features, e.g. validating certificates?
I did not know, you can remove elements by applying an overlay file. But
I am not talking about full DOM access. I just need access to the
elements defined/added in my overlay file.

> Removing all of the js script stuff reliably would likely require a
> library like DOMPurify, or a tag/attribute whitelist.
It is not enought to blacklist all on* attributes and to require src
attributes to be chrome urls or local urls in the api users xpi? We can
also check if the urls target exists. Is there really so much more
besides src attributes and on* attributes that needs to be looked after?

>> *3. Addons may break due to changes in the Thunderbird UI
>> *
>> That is true and it is the compromise I am asking for. But breaks due
>> to UI changes are easy to fix, you mostly have to update an ID. And
>> how often will the UI change, after all that XUL -> HTML transition
>> is done?
> The UI may change at any time, even if subtly. What would the
> depreciation strategy look like for making UI changes? Would
> Thunderbird developers need to track and document each element they
> are changing?
No, I do not want to add more work for you. The hg log shows already,
which UI files have been changed. That is the compromise I was talking
about, we have to adapt our addons.

> How would you handle extensions that break Thunderbird UI due to their
> overlays?
Hard to tell. Report it to review and disable or restrict to

> This is the Firefox deprecation policy, I feel that if we are allowing
> access to all nodes we would have to follow a such thing for basically
> any UI change.
Again, I am not asking for full DOM access. I want to add stuff. Can
current overlays actually modify existing elements? Did not know that.
Do not want that, just the 3 methods mentioned above.

It may be better for this discussion, if I just try to code the API, so
we can see what it really does and how useful it is in the end?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the tb-planning mailing list