<html>

  <head>

    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

  </head>

  <body>

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

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

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

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

  </body>

</html>