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