<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<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">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">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<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">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<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>
<style type="text/css">
.myName {
text-shadow: 1px 1px 2px #DDD;
transition:font-size 0.5s;
}
.myName:hover, .myName a:hover
{ font-size:13pt; text-shadow: 3px 3px 4px rgba(200,250,200,0.7);}
.moz-signature {opacity: 1.0 !important;}
.myName a { cursor: pointer !important; transition:font-size 0.5s;}
.myLogo {
transition: all .4s ease-out;
}
.myLogo:hover {
transform: scale(3) translate(-30px,-5px);
}
#mySignature, :not(blockquote) #mySignature {
background: rgb(230,240,163);
background-image: linear-gradient(to bottom, rgba(230,240,163,1) 0%,rgba(210,230,56,1) 50%,rgba(195,216,37,1) 51%,rgba(219,240,67,1) 100%);
color: #444;
box-shadow: 4px 4px 9px -2px rgba(0,0,0,0.65);
border-radius: 0.7em; padding: 0.8em 1.2em;
border: 1px dashed #8080A0;
font-size: 11pt !important;
font-family: 'Lucida Sans Unicode', 'Lucida Grande', sans-serif;
width: 65%;
}
.AddonList a {
color: #666666;
font-size: 10pt !important;
}
</style>
<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 <img style="margin-top: 1em; float:
right; box-shadow: 1px 1px 2px rgba(20, 20, 20, 0.4);"
moz-do-not-send="false" class="myLogo"
src="cid:part9.E84A165E.880E0D99@gmx.de" alt="Get
Thunderbird!" width="94" height="15"> </div>
</div>
<div id="smartTemplate4-quoteHeader">
<style type="text/css" scoped="">
#newHeaderAG1 b { font-weight:bold; color: #990033; min-width: 4.5em; max-width:none; display:inline-block;}
</style>
<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">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>
<br>
</body>
</html>