<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<br>
<div class="moz-cite-prefix">Am 12.10.2019 um 20:39 schrieb Philipp
Kewisch:<br>
</div>
<blockquote type="cite"
cite="mid:3E9A7C5E-BB68-42C9-A64F-F7D31ED10356@thunderbird.net">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr"><br>
<blockquote type="cite">On 12. Oct 2019, at 5:40 PM, John
Bieling <a class="moz-txt-link-rfc2396E" href="mailto:john.bieling@gmx.de"><john.bieling@gmx.de></a> wrote:<br>
</blockquote>
</div>
<blockquote type="cite">
<div dir="ltr">
<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>
I would go for simplicity here. No parent-matching or how that
feature might be called. A simple "add this before/after this
ID-Element" or "append to this ID-Element". These 3 types are for
example the only ones supported by my own OverlayManager
(appendto="id", insertbefore="id", insertafter="id").<br>
<br>
<blockquote type="cite"
cite="mid:3E9A7C5E-BB68-42C9-A64F-F7D31ED10356@thunderbird.net">
<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>
</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>
<br>
<blockquote type="cite"
cite="mid:3E9A7C5E-BB68-42C9-A64F-F7D31ED10356@thunderbird.net">
<div><br>
</div>
<div>How would you prevent extensions from removing UI elements
that belong to security features, e.g. validating certificates?</div>
</blockquote>
I did not know, you can remove elements by applying an overlay file.
But I am not talking about full DOM access. I just need access to
the elements defined/added in my overlay file.<br>
<br>
<blockquote type="cite"
cite="mid:3E9A7C5E-BB68-42C9-A64F-F7D31ED10356@thunderbird.net">
<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>
</blockquote>
It is not enought to blacklist all on* attributes and to require src
attributes to be chrome urls or local urls in the api users xpi? We
can also check if the urls target exists. Is there really so much
more besides src attributes and on* attributes that needs to be
looked after?<br>
<br>
<blockquote type="cite"
cite="mid:3E9A7C5E-BB68-42C9-A64F-F7D31ED10356@thunderbird.net">
<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?</blockquote>
No, I do not want to add more work for you. The hg log shows
already, which UI files have been changed. That is the compromise I
was talking about, we have to adapt our addons. <br>
<br>
<blockquote type="cite"
cite="mid:3E9A7C5E-BB68-42C9-A64F-F7D31ED10356@thunderbird.net">
<div><br>
</div>
<div>How would you handle extensions that break Thunderbird UI due
to their overlays?<br>
</div>
</blockquote>
Hard to tell. Report it to review and disable or restrict to
last-known-working-version?<br>
<br>
<blockquote type="cite"
cite="mid:3E9A7C5E-BB68-42C9-A64F-F7D31ED10356@thunderbird.net">
<div>
<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>
</blockquote>
Again, I am not asking for full DOM access. I want to add stuff. Can
current overlays actually modify existing elements? Did not know
that. Do not want that, just the 3 methods mentioned above.<br>
<br>
<br>
It may be better for this discussion, if I just try to code the API,
so we can see what it really does and how useful it is in the end?<br>
</body>
</html>