Proposal: MailExtensions API to allow UI overlays, but no script injection
john.bieling at gmx.de
Sat Oct 12 06:25:54 UTC 2019
For my bootstrapped extensions I wrote my own overlay loader which is about 500 lines of code. It is not very complicated and self-contained without dependencies but of course is not a clone of the original one.
I can contribute the overlay API.
Please reconsider pulling the plug.
Why is it, extension should no longer be able to style the UI as before? What is the argument?
> Am 12.10.2019 um 00:07 schrieb Geoff Lankow <geoff at thunderbird.net>:
> Let me add to this.
> Having an overlay loader is really bloody complicated. The amount of code we have for even the current buggy loader, the number of dirty hacks, and the places its cancerous tentacles reach is frankly insane.
> Now I don't totally buy in to some of the arguments being made here and elsewhere by others on the Thunderbird team, and I am an extension writer who uses overlays, but I still think the all-powerful overlay loader needs to go. Yes, there needs to be some points where you or I can change specific things about the user interface with an extension, but having the ability to change any window and do anything to it can not and should not continue.
> On 11/10/2019 21:36, Philipp Kewisch wrote:
>> Hi John,
>> I understand the desire to be able to overlay arbitrary UI elements, and I agree it is a powerful API to have.
>> The issue with a such API is however specifically the stability. If we allow extensions to make arbitrary changes to the address book for example, we could never change anything in the address book without risking add-on compatibility issues.
>> This is true now, where we still use xul, but also true when the UI is relatively stable. We would essentially have to make deprecation notices for every single patch in the UI, describing exactly what changed and how to migrate.
>> Injecting DOM and then having access to that node will also allow developers to circumvent any protections and execute scripts. Just imagine the good ol' <img src="dfdghh" onerror="evil()"/>
>> What does fit in well for WebExtensions is using UI that is easily secluded from the rest, and either declaratively defines how the UI manipulation should happen, so that the API can be changed if the UI changes, or is separate in an iframe that is managed by the API.
>> Admittedly, Thunderbird has more places where adding UI makes sense, so we would have more APIs than Firefox, but anything that allows arbitrary access runs into the issues I described above.
>>> On 10. Oct 2019, at 10:04 PM, John Bieling <john.bieling at gmx.de> wrote:
>>> In the last days I tried to understand the reasons behind the latest
>>> announcements regarding legacy extensions. The reasons given so far are
>>> - security issues
>>> - stability issues (in terms of addons breaking so often, because stuff
>>> changed in Thunderbird)
>>> WebExtensions improve these things, but also restrict addon authors
>>> creativity substantially. We would need to ask for every bit of UI
>>> manipulation and we will depend on your good will. This is not a healthy
>>> relationship. I would like to bring back that creativity without
>>> compromising security.
>>> Once the transition from XUL to HTML has been completed, I assume, the
>>> Thunderbird UI will be stable again. So "overlaying" the Thunderbird UI
>>> should not cause so many stability issues. The current legacy overlay
>>> mode allows to inject scripts, which is the cause of the security issue.
>>> The new Overlay API should ignore any scripts and be invoked from the
>>> background.js like so:
>>> and it should fire an onload event or something like that if any of the
>>> registered overlays has been injected and we can than further manipulate
>>> the DOM with wathever is allowed in WebExtension.
>>> That would get rid of the need to write hundreds of different UI APIs.
>>> Overlaying is not a bad thing, it is a very powerful and easy way to
>>> extend a given UI.
>>> Please give us back the power we deserve.
>>> tb-planning mailing list
>>> tb-planning at mozilla.org
>> tb-planning mailing list
>> tb-planning at mozilla.org
> tb-planning mailing list
> tb-planning at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tb-planning