<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body smarttemplateinserted="true">
<br>
<blockquote type="cite"
cite="mid:BBDA81E1-3F73-420E-B326-75FB8A881626@thunderbird.net"><br>
<blockquote type="cite">
<div dir="ltr">
<blockquote type="cite"
cite="mid:3E9A7C5E-BB68-42C9-A64F-F7D31ED10356@thunderbird.net">
<blockquote type="cite">
<div dir="ltr">
<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>
</blockquote>
The idea was to have an event fired after a registered overlay
has been injected into a window, which the api user can
subscribe to. Here my knowledge about WebExt is still to
limited to outline this further, but maybe the event returns
an object with "id: element" members of the added elements and
we can then do something with them, like adding event handlers
to execute JS functions available in the webExt context. That
would also seperate UI and logic.<br>
</div>
</blockquote>
<div><br>
</div>
<div>This might be an area to look in to more then. As soon as you
have one element of a dom tree, you have full access to the dom.
For example,
element.appendChild(element.ownerDocument.createElement("script")).
Or
element.ownerDocument.querySelector("img").setAttribute("onerror",
"evil()")</div>
<div><br>
</div>
<div>Therefore, if you want interactive elements then you'll
likely end up with a declarative API.</div>
<div><br>
</div>
<div>I'm also not sure you can pass DOM nodes around in
WebExtension APIs, they are meant to work across process
boundaries and passing raw nodes would likely also break the
upcoming site isolation.</div>
</blockquote>
<p>what about the "chrome context" is that going away completely? <br>
</p>
<p>There is an awful lot talk about <b>sites </b>/ content tabs /
the browser etc. which I feel isn't really relevant to mail. This
is all so Firefox / browser centric.<br>
</p>
<p>Does mail live in a "site context"? Would it be "one site per
mail server / account"? Would then something like moving mails
from one account to another be prohibited?<br>
</p>
<p>What about instant messages?</p>
<p>My view is that the downloaded mails are not living in a site
context anymore, they belong to the user; same when composing an
email. That's where the really useful Add-ons work in my
perspective. Thunderbird is not a web browser. :)<br>
</p>
<p>Axel<br>
</p>
<br>
</body>
</html>