<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body smarttemplateinserted="true">
    <div class="moz-cite-prefix">
      <p>My point exactly - but then maybe I just cannot imagine it
        right now - maybe it is possible to make API points specifically
        for adding UI elements (in the case of address book, this could
        be added fields or decks). I think that's why we need to present
        this to the core development team to discuss. Often I have a
        feeling we are not even talking the same language. Screenshots
        may leave core people dumbfounded and do not really tell too
        much about the <i>requirements</i> we are truing to fulfill for
        the user.</p>
      <p>Axel<br>
      </p>
    </div>
    <div class="moz-cite-prefix">On 11/10/2019 10:57, John Bieling
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:6791d903-484a-ba6b-9e98-408e8bc28822@gmx.de">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <tt>Can we not find a compromise here? You have not changed the
        addressbook UI for years and I needed to do a lot of
        modifiations to make it fit for CardDAV. There is no way, you
        can write an API for that:<br>
        <br>
        <br>
        <br>
        John<br>
        <br>
        <br>
      </tt><br>
      <br>
      <div class="moz-cite-prefix">Am 11.10.2019 um 10:36 schrieb
        Philipp Kewisch:<br>
      </div>
      <blockquote type="cite"
        cite="mid:6A19E843-3661-46A7-99A8-FFA22EFBB1CC@thunderbird.net">
        <pre class="moz-quote-pre" wrap="">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.

Philipp



</pre>
        <blockquote type="cite">
          <pre class="moz-quote-pre" wrap="">On 10. Oct 2019, at 10:04 PM, John Bieling <a class="moz-txt-link-rfc2396E" href="mailto:john.bieling@gmx.de" moz-do-not-send="true"><john.bieling@gmx.de></a> 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:

browser.overlay.registerOverlay(<a class="moz-txt-link-rfc2396E" href="chrome://messenger/content/addressbook/abNewCardDialog.xul" moz-do-not-send="true">"chrome://messenger/content/addressbook/abNewCardDialog.xul"</a>,
"overlays/abNewCardWindow.xul");

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.

John

_______________________________________________
tb-planning mailing list
<a class="moz-txt-link-abbreviated" href="mailto:tb-planning@mozilla.org" moz-do-not-send="true">tb-planning@mozilla.org</a>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/tb-planning" moz-do-not-send="true">https://mail.mozilla.org/listinfo/tb-planning</a>
</pre>
        </blockquote>
        <pre class="moz-quote-pre" wrap="">_______________________________________________
tb-planning mailing list
<a class="moz-txt-link-abbreviated" href="mailto:tb-planning@mozilla.org" moz-do-not-send="true">tb-planning@mozilla.org</a>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/tb-planning" moz-do-not-send="true">https://mail.mozilla.org/listinfo/tb-planning</a>
</pre>
      </blockquote>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
tb-planning mailing list
<a class="moz-txt-link-abbreviated" href="mailto:tb-planning@mozilla.org">tb-planning@mozilla.org</a>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/tb-planning">https://mail.mozilla.org/listinfo/tb-planning</a>
</pre>
    </blockquote>
  </body>
</html>