<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Thanks Axel,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">this list makes a lot of sense. Once we
are further down the road we can collect this information from
everyone in a more streamlined fashion and work on the
experiments.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Regarding the content code, I just
mentioned this since due to bug 1272869 you can't do it in the
background page, so you'd need a content page to trigger the
clipboard. What content scripts would look like for mail I don't
know yet. At a minimum, it would work on pages loaded via
openTab("contentTab", ...).</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Philipp<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 4/22/18 1:19 AM, Axel Grude wrote:<br>
</div>
<blockquote type="cite"
cite="mid:afb30ddc-8f6d-7e45-e327-83406cc7f512@gmail.com">
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
<div id="smartTemplate4-template">
<p>Dear Philipp,</p>
<p>I can definitely do a functional breakdown. Among other
things, I do stuff like</p>
<ul>
<li>set up folder listeners</li>
<li>show the number of unread mails in folders + subfolders<br>
</li>
<li>deep cloning and persisting of filters</li>
<li>expanding the filter search capabilities<br>
</li>
<li>modify folder tree icons</li>
<li>create full on drag and drop tabs in a separate toolbar (a
lot of this is in code, so it should be easy enough to port)</li>
<li>recreate the "Nostalgy" experience of an auto-filling
folder search bar</li>
<li>offer additional interfaces / buttons for mail / folder
specific commands<br>
</li>
</ul>
<p>these are only a few of the things, but they would require
quite a few APIs, I think <br>
</p>
<p><i>I may completely misunderstand, but... </i><br>
</p>
<p>...as regards the clipboard I am not working within content
area (I do not modify mail contents or browser tabs) but in
the chrome context for my own data (in a XUL preferences
dialog, for internal data and license strings). A lot of the
restrictions of API related stuff that tries to drive Add-ons
into "only work within content" are non-starters we need to
work on meta-data, stuff like folders, message headers, filter
rules etc. I am afraid web extensions have no idea that a lot
of the work we do is "enhancing the database fat client that
is Thunderbird" and that hasn't much to do with fiddling with
HTML content. I do not necessarily need to build new content
tabs for displaying this information but just interface with
the existing UI. Do emails even count as "content" or is it
just the body of an email when it is in an email tab?</p>
<p>As I said maybe there is some confusion here with the
definition of "content" I don't find it very helpful in a mail
client? As far as I understand we are using the Gecko engine
to display the content of emails, and it is doing this _very
very well_. Most Add-ons that are mail-centric add more data /
convenience functions that do not interfere in that area. <br>
</p>
<p>Could you expand what "<i>content</i>" means in the
THunderbird / Mail context and what's the thinking about
restricting Add-ons to work on only that and not on lower
level data? I think that restriction is what crippled the
Add-ons scene on Firefox when Quantum was released ( a lot of
people switched to chrome because the differences in
configurability were so diminished ). Is it really a matter of
Add-ons developers being less trustworthy than browser
developers?<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.mozilla.org/thunderbird/addon/quickfolders-tabbed-folders/"
moz-do-not-send="true">QuickFolders</a>, <a
href="https://addons.mozilla.org/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.mozilla.org/thunderbird/addon/zombie-keys/"
moz-do-not-send="true">Zombie Keys</a>, <a
href="https://addons.mozilla.org/thunderbird/addon/smarttemplate4/"
moz-do-not-send="true">SmartTemplate4</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:part8.AC1DF624.C1655F56@thunderbird.net"
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: Supporting future
addon development<br>
<b>From:</b>Philipp Kewisch <a
class="moz-txt-link-rfc2396E"
href="mailto:kewisch@thunderbird.net"
moz-do-not-send="true"><kewisch@thunderbird.net></a><br>
<b>To:</b>Thunderbird Planning (Moderated) <br>
<b>Sent: </b>Saturday, 21/04/2018 19:45:34 19:45 GMT ST
+0100 [Week 16]<br>
</div>
</blockquote>
</div>
<blockquote type="cite"
cite="mid:48E8EABC-CA55-4E9C-A169-CB390E70099E@thunderbird.net"
id="mid_48E8EABC_CA55_4E9C_A169_CB390E70099E_thunderbird_net"
class=" cite">
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
<div><br>
</div>
<div><br>
On 21. Apr 2018, at 6:43 PM, Axel Grude <<a
href="mailto:axel.grude@gmail.com" moz-do-not-send="true">axel.grude@gmail.com</a>>
wrote:<br>
<br>
</div>
<blockquote type="cite" id="Cite_211168" class=" cite">
<div>
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
<div id="smartTemplate4-template">
<p>Dear Philipp,</p>
<p> </p>
<blockquote type="cite" id="Cite_2682062" class=" cite">
<pre wrap="">One such experiment, which I feel is very promising, is to introduce WebExtensions, but with a twist: there is an escape hatch to legacy technology. This means you can continue to run legacy add-ons, and all you need to do is use a specific manifest.json property, and drop the install.rdf.</pre>
</blockquote>
<p>this is excellent news. We really don't mind adapting
to the changes, but that is a lot better than taking
away XPCOM and overlays completely. Let there be some
pain! :)</p>
</div>
</div>
</blockquote>
<div><br>
</div>
<br>
<blockquote type="cite" id="Cite_6431870" class=" cite">
<div>
<div id="smartTemplate4-template">
<p> </p>
<blockquote type="cite" id="Cite_5854825" class=" cite">
<pre wrap="">If we go forward with this approach, it would not make sense to keep this backdoor open forever. We would have yet another technology to maintain, and add-on devs will have an increasing amount of gecko changes to make. In the end, both sides will fold under maintenance burden.</pre>
</blockquote>
At which stage there will be an obvious choice to make for
Add-on developers: rewrite (and take a lot of functional
loss plus many months of work) or fork Thunderbird (if
that is a legal option). I know Waterfox didn't exactly
set out with this goal but it happens to be the only
alternative for many Addon authors who want a half way up
to date code base.</div>
</div>
</blockquote>
<div><br>
</div>
I think this is a decision that the add-on developer needs to
take much earlier. It seems to me you are averse to doing a full
rewrite.
<div><br>
</div>
<div>No matter what tech is used, if you don’t go with changes
you will eventually have to do a complete rewrite anyway.
<div><br>
</div>
<div>If you are already gradually adapting your code to gecko
changes, you could just as well adapt to writing new
WebExtension APIs. If you do that in small pieces over time,
you’ll never need to do a full rewrite.</div>
<div><br>
</div>
<div>Keeping the license terms in mind anyone can of course
fork Thunderbird, but I’d much rather have those who would
do so work with the Thunderbird community to improve the
APIs we introduce. Again, anything that dwells on the old
tech is spending a lot of resources to stand still.<br>
<blockquote type="cite" id="Cite_9955161" class=" cite">
<div>
<div id="smartTemplate4-template">
<p> </p>
<blockquote type="cite" id="Cite_6914249" class="
cite">
<pre wrap="">A such API from my example has a high chance of being accepted in Thunderbird (after all, what would a mail api be without it?). This shifts the burden to Thunderbird core developers, and if we completely change the new mail notification mechanism, or a gecko api goes away, it would not affect you as a user of the WebExtension API.
This way, we can involve add-on developers in creating general use apis, so that you don’t have to fear all the functionality being taken away from you. Once we have a good amount of general apis, we can consider closing the backdoor.</pre>
</blockquote>
I don't understand everything fully, but please keep
us informed. Ray wanted to set up a weekly Add-on
developers talk on google, I think this would be an
excellent platform to discuss these newer
technologies.</div>
</div>
</blockquote>
<div><br>
</div>
I will most certainly keep folks informed about my progress!<br>
<blockquote type="cite" id="Cite_7564788" class=" cite">
<div>
<div id="smartTemplate4-template">
<p> </p>
<blockquote type="cite" id="Cite_8562579" class="
cite">
<pre wrap="">For those considering to rewrite as a bootstrapped add-on, please instead consider going the WebExtension API route. If Gecko gets rid of bootstrapped add-ons you’d have twice the work.
This isn’t a final plan, we’ve just started experimenting. Therefore I can’t give you specific instructions on what you need to change in your add-on just yet. If you would like to help out in creating new APIs for Thunderbird and testing out this functionality please get in touch</pre>
</blockquote>
I would definitely like to help there I would need
some wrappers for XPCOM interfaces I currently use
many many times:<br>
<p><tt>nsIMsgComposeService,
nsIClipboard,nsIWindowMediator, nsIWindowWatcher,
nsITransferable (for drag & drop),
nsIFolderListener, nsIMsgSearchSession,
nsILocalFile / nsIFile, nsIMsgFolder, </tt><tt><tt>nsIMsgDBHdr,
</tt>nsIMsgFilterList, nsIMsgIncomingServer,
nsIPromptService, nsIMsgGlobalIndex,
nsITreeBoxObject, nsIURI, nsIMsgAccountManager,
nsIMsgAccount, nsIFilePicker, nsIFocusManager,
nsIStyleSheetService, nsIMsgMailSession,
nsIXULAppInfo, nsIXULRuntime, nsIRDFResource,
nsIMsgCopyService, nsIConsoleService,
nsIScriptError, nsIExternalProtocolService,
nsIObserverService, nsIImapIncomingServer,
nsIUrlListener, nsIMsgFilter, nsIMsgRuleAction,
nsIMsgSearchTerm, nsIVersionComparator,
nsIMsgHeaderParser, nsIMsgTagService</tt><br>
</p>
<p>a lot of these interfaces may already be covered by
APIs, I do not know because I did not start simply
rewriting based on a hunch that I may need to learn
these technologies in mail.</p>
<p>If these interfaces go away for scripting will they
also not be used by the internal code base of
Thunderbird (is Thunderbird forced to eat their own
dog food and use the APIs as well)? I think this
would ensure a full coverage of all needed APIs on
the rewrite.<br>
</p>
</div>
</div>
</blockquote>
<div>Instead of breaking this down to the exact interface
used I think it makes more sense to collect high level use
cases. From your list for example, I could see:</div>
<div>- ability to create new windows and observe windows
opened (browser.windows.*)</div>
<div>- interact with the clipboard (might work already using
the html5 clipboard api, could be that we need “content
scripts” though)</div>
<div>- getting platform info (browser.runtime.*)</div>
<div>-logging to the error console (console.log)</div>
<div><br>
</div>
<div>The following don’t exist yet;</div>
<div>-searching and otherwise interacting with messages,
folders and accounts </div>
<div>- access to filtering incoming emails </div>
<div><br>
</div>
<div>Philipp </div>
<blockquote type="cite" id="Cite_8461062" class=" cite">
<div>
<div id="smartTemplate4-template">
<p> </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.mozilla.org/thunderbird/addon/quickfolders-tabbed-folders/"
moz-do-not-send="true">QuickFolders</a>, <a
href="https://addons.mozilla.org/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.mozilla.org/thunderbird/addon/zombie-keys/"
moz-do-not-send="true">Zombie Keys</a>, <a
href="https://addons.mozilla.org/thunderbird/addon/smarttemplate4/"
moz-do-not-send="true">SmartTemplate4</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
<thunderbird_blog2.png> </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;" id="Cite_3942052" class=" cite">
<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:
Supporting future addon development<br>
<b>From:</b>Philipp Kewisch <a
class="moz-txt-link-rfc2396E"
href="mailto:kewisch@thunderbird.net"
moz-do-not-send="true"><kewisch@thunderbird.net></a><br>
<b>To:</b>Thunderbird Planning (Moderated) <br>
<b>Sent: </b>Saturday, 21/04/2018 16:27:26 16:27
GMT ST +0100 [Week 16]<br>
</div>
</blockquote>
</div>
<blockquote type="cite"
cite="mid:A2F49B29-C4D9-4B45-A37F-61E2AF97BAC5@thunderbird.net"
id="mid_A2F49B29_C4D9_4B45_A37F_61E2AF97BAC5_thunderbird_net"
class="
 cite">
<pre wrap="">Hi folks
I agree a lot with Magnus here, we are looking into alternatives going forward. It is true that starting with Thunderbird 61, legacy xul add-ons are no longer supported by the Mozilla Platform. We could certainly cling to this tech and fork m-c, but this also means we would spend a great amount of effort in recreating the old technology just to stand still.
We are experimenting with various approaches for extension authors to continue to maintain their add-ons with only minimal migration effort.
One such experiment, which I feel is very promising, is to introduce WebExtensions, but with a twist: there is an escape hatch to legacy technology. This means you can continue to run legacy add-ons, and all you need to do is use a specific manifest.json property, and drop the install.rdf.
On the plus side, you don’t need to go about a rewrite of your add-on. We don’t have all the APIs you need anyway. On the other hand, you are still responsible for adapting to Gecko changes which can be high pace, as it has already been.
If we go forward with this approach, it would not make sense to keep this backdoor open forever. We would have yet another technology to maintain, and add-on devs will have an increasing amount of gecko changes to make. In the end, both sides will fold under maintenance burden.
To counteract, we would additionally enable “WebExtension Experiments” on release. This is a way for an add-on to provide a WebExtension API, which is itself is implemented using internal gecko APIs. You could for example for example create an API that provides a listener that fires on new mail arriving. The api uses the internal observers you know and love on the inside, but could provide a simple browser.mailRequest.onEmailArriving.addListener() api on the outside.
A such API from my example has a high chance of being accepted in Thunderbird (after all, what would a mail api be without it?). This shifts the burden to Thunderbird core developers, and if we completely change the new mail notification mechanism, or a gecko api goes away, it would not affect you as a user of the WebExtension API.
This way, we can involve add-on developers in creating general use apis, so that you don’t have to fear all the functionality being taken away from you. Once we have a good amount of general apis, we can consider closing the backdoor.
For those considering to rewrite as a bootstrapped add-on, please instead consider going the WebExtension API route. If Gecko gets rid of bootstrapped add-ons you’d have twice the work.
This isn’t a final plan, we’ve just started experimenting. Therefore I can’t give you specific instructions on what you need to change in your add-on just yet. If you would like to help out in creating new APIs for Thunderbird and testing out this functionality please get in touch.
Philipp
> On 21. Apr 2018, at 4:05 PM, Magnus Melin <a class="moz-txt-link-rfc2396E" href="mailto:mkmelin+mozilla@iki.fi" moz-do-not-send="true"><mkmelin+mozilla@iki.fi></a> wrote:
>
> We're still working to see if it's viable to allow the traditional overlay mechanism for 61 and beyond, Patrick B has a patch to simulate it using JavaScript.
> But bootstrapped add-ons, which will at least still be supported, can change/access anything overlay add-ons can, so there is no loss in functionality. Only that it's a bit more elaborate to do.
>
> -Magnus
>
>> On 21-04-2018 16:53, Axel Grude wrote:
>> Both at least XPCOM access and the overlay mechanisms are vital for writing functioning "deep" add-ons (whether you label that legacy or some other term doesn't really matter and does not detract from the fact that it is currently not replaced with a viable alternative that gives full access to everything.
> _______________________________________________
> 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>
_______________________________________________
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>
</div>
</blockquote>
<blockquote type="cite" id="Cite_1678617" class=" cite">
<div><span>_______________________________________________</span><br>
<span>tb-planning mailing list</span><br>
<span><a href="mailto:tb-planning@mozilla.org"
moz-do-not-send="true">tb-planning@mozilla.org</a></span><br>
<span><a
href="https://mail.mozilla.org/listinfo/tb-planning"
moz-do-not-send="true">https://mail.mozilla.org/listinfo/tb-planning</a></span><br>
</div>
</blockquote>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<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>
<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>
<p><br>
</p>
</body>
</html>