<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr">Magnus' approach would definitely fit well in terms of providing access to content windows. It would however still allow script injection into Thunderbird UI, allow bypassing the permission system completely, allow developers to unintentionally break the Thunderbird UI, and make it difficult to change the UI without breaking add-on compat, and possibly some of the other downsides I mentioned. I'd love to hear how this would be mitigated. </div><div dir="ltr"><br></div><div dir="ltr">I'm not sure how we can resolve this thread in a satisfactory way, I'd really like to. There are certainly downsides to my suggestions as well, so it is really a matter of weighing the risks and deciding which aspects are more important. </div><div dir="ltr"><br></div><div dir="ltr">What might work is for now, is for you to use your overlays in an experiment, identifying use cases for more specific APIs along the way. </div><div dir="ltr"><br></div><div dir="ltr">When Thunderbird UI is mostly in content, we can re-evaluate how to proceed with what level of access we'd give to extension developers. By this time we'll be in a completely different situation, have more apis, and it is possible they'd cover the majority of use cases.</div><div dir="ltr"><br></div><div dir="ltr">Would this be acceptable?</div><div dir="ltr"><br></div><div dir="ltr">Philipp </div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br><blockquote type="cite">On 17. Oct 2019, at 2:59 PM, Magnus Melin <mkmelin+mozilla@iki.fi> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>Yes, you understood it correctly. We're not there yet though.<br>
</p>
<p> -Magnus<br>
</p>
<div class="moz-cite-prefix">On 17-10-2019 11:06, John Bieling
wrote:<br>
</div>
<blockquote type="cite" cite="mid:6609eb51-5720-c2fe-e75b-86cdcc61fb6b@gmx.de">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<tt>WOW, that would make such a big difference, as I believe
WebExtensions can alter/access DOM of content pages, right? Or
did I misunderstood the definition?<br>
</tt><br>
<tt><a href="https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Content_scripts" moz-do-not-send="true">https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Content_scripts</a><br>
<br>
That would mean, we can alter the UI again. Correct?<br>
<br>
John<br>
<br>
<br>
<br>
</tt>
<div class="moz-cite-prefix">Am 17.10.2019 um 09:32 schrieb Magnus
Melin:<br>
</div>
<blockquote type="cite" cite="mid:39e0f158-adbb-a9cd-0b9b-622f09db48e1@iki.fi">
<p>In one way yes it could kind of work kind of like that I
think, with a significant twist, and with some limitations,
and only on the longer horizon.</p>
<p>It's not yet clear exactly what technical barriers there are
(a bunch for sure, potentially less than one would think
though), but... one step at a time. Currently the Thunderbird
UI is living in chrome. Most of it would be better off running
in content. What I mean is, the 3pane and what makes up the
main UI should really just be *seen as* a very fat web
application running in a browser tab. With XBL now gone, and
UI moving over to from XUL to HTML (last release with XUL is
probably the 78 release), it's getting more and more feasible.<br>
</p>
<p>With that in mind, what you would have is Thunderbird as the
web page (internally, technically, so not really, but still),
and as an add-on author you could interact with that page the
same way WXs can interact with normal web content. This is
basically what WXs are designed for so it fits in very well.
The add-on would have the powers it needs (though no XPCOM),
and the Thunderbird UI has the powers of a content page,
interacting with a back-end through suitable means (either
http or data put into web compatible local storage mechanisms
by the back-end).<br>
</p>
<p> -Magnus<br>
</p>
<div class="moz-cite-prefix">On 16-10-2019 15:31, Axel Grude
wrote:<br>
</div>
<blockquote type="cite" cite="mid:cfdaccb6-a0da-45a0-c1df-fbba18a9b778@gmail.com">
<div id="smartTemplate4-template">
<p>Eyal wrote:<br>
</p>
<blockquote type="cite">Extensions should be able to do
essentially everything. Certainly everything the TB's <u><b>own
UI</b></u> code can do. </blockquote>
(emphasis by me) <br>
<p>That's essentially echoing what my thought was about
"Thunderbird eating it's own dog food", so let me
re-iterate the question:</p>
<p><font color="#bf00bf"><b>How would a Thunderbird
developer re-design the API if they were forced to use
it in their own front-end (JavaScript) code?</b></font></p>
<p>This question may sound a little ridiculous at first
glance, but it is an interesting thought experiment,
because it forces the Core Developer to think about the
restrictions proposed on us who want to add *more
functionality* and *improve existing functions*. If you
think about it our goals aren't vastly different to those
from thunderbird core.</p>
<p>If the API is the "safe point" for the front end, then
why not force Thunderbird Core code through the same gate?
Possible answers</p>
<ul>
<li>Core needs to do more than Add-ons <br>
(which is partly true, but Add-ons add stuff that core
didn't think of and users still find useful, so it also
goes the other way)</li>
<li>Core code is vetted and Firefox does not review web
extensions code<br>
(so far we did manually review and vet the code for
security with the Add-on reviewers crew. Which mainly
consists of other developers. Whether this is a big
problem going forward remains debatable; AFAIK there was
*one* documented security breach caused by an ADd-on in
Tb within the last 10 years, which is not a bad
statistic compared to OS like windows)</li>
<li>Core Developer are Trusted, anyone can develop
Add-ons<br>
(I think this a stronger argument; the question is
whether it would be possible to have specially vetted /
trusted Add-on developers and only allow them XPCOM
access and how to vet these people - A strong
committment to the user base and regular maintenance,
bug fixing etc. would be good markers to start from. So
far I assumed there wasn't such a big difference in the
development community, except that core devs could be
financed by the foundation, whereas addon devs had to
organize monetization themselves. Maybe that aspect
needs to be solved at the same time.)</li>
</ul>
<p>I would still be very interested in at least one of the
core devs going through this thought experiment, even if
just to come to the conclusion that it's impossible. It
may be not? Or it may lead to a completely different
answer.<br>
</p>
<p>Axel<br>
</p>
<div id="mySignature"> <b class="myName"><a href="mailto:axel.grude@gmail.com" moz-do-not-send="true">Axel Grude</a></b> <br>
Music Production and Composition <br>
Thunderbird Add-ons Developer <span class="AddonList">(<a href="https://addons.thunderbird.net/thunderbird/addon/quickfolders-tabbed-folders/" moz-do-not-send="true">QuickFolders</a>, <a href="https://addons.thunderbird.net/thunderbird/addon/quickfilters/" moz-do-not-send="true">quickFilters</a>, <a href="https://addons.mozilla.org/firefox/addon/quickpasswords/" moz-do-not-send="true">QuickPasswords</a>, <a href="https://addons.thunderbird.net/thunderbird/addon/zombie-keys/" moz-do-not-send="true">Zombie Keys</a>, <a href="https://addons.thunderbird.net/thunderbird/addon/smarttemplate4/" moz-do-not-send="true">SmartTemplate⁴</a>)</span> <br>
Visit my <a href="https://www.youtube.com/c/thunderbirddaily" moz-do-not-send="true">YouTube Channel</a> for email
productivity tips <div><thunderbird_blog2.png></div> </div>
</div>
<div id="smartTemplate4-quoteHeader">
<blockquote type="cite" style="margin-bottom: -20px
!important; padding-bottom:20px !important;">
<div id="newHeaderAG1" style="font-size: x-small;
padding:1em; background-color:rgba(220,220,240,0.4);
border-radius:3px;"> <b>Subject:</b>Re: Proposal:
MailExtensions API to allow UI overlays, but no script
injection<br>
<b>From:</b>Eyal Rozenberg <a class="moz-txt-link-rfc2396E" href="mailto:eyalroz@technion.ac.il" moz-do-not-send="true"><eyalroz@technion.ac.il></a><br>
<b>To:</b>Thunderbird Planning (Moderated) <a class="moz-txt-link-rfc2396E" href="mailto:tb-planning@mozilla.org" moz-do-not-send="true"><tb-planning@mozilla.org></a>;
John Bieling <a class="moz-txt-link-rfc2396E" href="mailto:john.bieling@gmx.de" moz-do-not-send="true"><john.bieling@gmx.de></a>
<br>
<b>Sent: </b>Saturday, 10/12/2019, 15:56 15:56 IST
+0100 [Week 41]<br>
</div>
</blockquote>
</div>
<blockquote type="cite" cite="mid:6aaaa2fc-c47d-7a8b-51c3-3de14d82f2db@technion.ac.il">Sorry
for sounding like a broken record, but: <br>
<br>
On 12/10/2019 9:25, John Bieling wrote: <br>
<blockquote type="cite">Why is it, extension should no
longer be able to style the UI as before? </blockquote>
<br>
... not just the UI. Extensions should be able to do
essentially everything. Certainly everything the TB's own UI
code can do. <br>
<br>
Eyal <br>
_______________________________________________ <br>
tb-planning mailing list <br>
<a class="moz-txt-link-abbreviated" href="mailto:tb-planning@mozilla.org" moz-do-not-send="true">tb-planning@mozilla.org</a> <br>
<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>
<br>
. <br>
</blockquote>
<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" 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>
<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" 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>
<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></body></html>