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

Eyal Rozenberg eyalroz at technion.ac.il
Sat Oct 12 21:27:37 UTC 2019



On 12/10/2019 21:39, Philipp Kewisch wrote:
> 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'm sure the edge cases should not blow up 500 loc into 10,000 loc...

>> We simply disallow any JS

Disagree with John Bieling on this point. I'd say: "We simply allow JS". 
Is it a security issue? You bet! ... As much of a security issue as 
installing an independent application. Which is just fine.

> 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?

The UI is part of the source repository, and changes _are_ tracked right 
now. At worst - devs will need to do nothing. At best (for extension 
devs) - Thunderbird devs will need to present prospective UI-changing 
builds for consultation by extension devs before they release these 
changes. We should be able to coexist somewhere along that spectrum.


> How would you handle extensions that break Thunderbird UI due to their 
> overlays?

Like extensions which do that today. It's the extension developer's problem.


> 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.
> 
> https://wiki.mozilla.org/WebExtensions/DeprecationPolicy

Instead of fixing the UI specifics as part of an API - which wasn't the 
case for TB so far - just leave it unfixed, so there's nothing to 
deprecate. The UI access and manipulation is part of the API; again, 
that's what we have now.


More information about the tb-planning mailing list