<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr">Thanks for focusing the discussion, I much appreciate!</div><div dir="ltr"><br><blockquote type="cite">On 12. Oct 2019, at 5:40 PM, John Bieling <john.bieling@gmx.de> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr">
  
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  
  
    <p>Now before the thread derails, I would like to sum up. I think I
      invalidated all arguments raised so far:</p>
    <p><b>1. Overlay is a code monster</b></p>
    <p>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.</p>
    <p>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.</p></div></blockquote><div><br></div>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.<br><blockquote type="cite"><div dir="ltr">
    <p><br>
    </p>
    <p><b>2. Overlay is a security issue</b></p>
    <p>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.</p></div></blockquote><div>If no js is running, how would you for example insert a button to click on?</div><div><br></div><div>How would you prevent extensions from removing UI elements that belong to security features, e.g. validating certificates?</div><div><br></div><div>Removing all of the js script stuff reliably would likely require a library like DOMPurify, or a tag/attribute whitelist.</div><div><br></div><blockquote type="cite"><div dir="ltr">
    <p><br>
    </p>
    <p><b>3. Addons may break due to changes in the Thunderbird UI<br>
      </b></p>
    <p>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?<br></p></div></blockquote>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?<div><br></div><div>How would you handle extensions that break Thunderbird UI due to their overlays?<br><div><br></div><div>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.</div><div><br></div><div><p style="margin: 0px; font-stretch: normal; line-height: normal; font-family: Helvetica;">https://wiki.mozilla.org/WebExtensions/DeprecationPolicy</p><div><br></div><div><blockquote type="cite"><div dir="ltr"><p>
    </p>
    <p><br>
    </p>
    <p>My knowledge about webext API is very very low, and I think I
      will need 10x more time than you to turn (for example) my
      OverlayManager into a proof-of-concept experiment. But I will go
      that extra mile, if you promise to consider it for core.</p>
    <p>John</p>
    <p><br>
    </p>
  

<span>_______________________________________________</span><br><span>tb-planning mailing list</span><br><span>tb-planning@mozilla.org</span><br><span>https://mail.mozilla.org/listinfo/tb-planning</span><br></div></blockquote></div></div></div></body></html>