<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=windows-1252">
</head>
<body smarttemplateinserted="true" text="#000000" bgcolor="#FFFFFF">
<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">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/">QuickFolders</a>,
<a
href="https://addons.mozilla.org/thunderbird/addon/quickfilters/">quickFilters</a>,
<a
href="https://addons.mozilla.org/firefox/addon/quickpasswords/">QuickPasswords</a>,
<a
href="https://addons.mozilla.org/thunderbird/addon/zombie-keys/">Zombie
Keys</a>, <a
href="https://addons.mozilla.org/thunderbird/addon/smarttemplate4/">SmartTemplate4</a>)</span>
<br>
Visit my <a href="https://www.youtube.com/c/thunderbirddaily">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.71ADFA79.C478C712@gmail.com" alt="Get
Thunderbird!" height="15" width="94">
</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"><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">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>
<br>
</body>
</html>