In order to simplify things, and to enable addons.thunderbird.net to receive upgrades much earlier than would otherwise have been possible, I have changed the way bootstrapped extensions are loaded in Thunderbird. They now require a manifest.json file like overlay extensions do, but with the addition of a "type" attribute on the "legacy" key, like so: { "manifest_version": 2, .... "legacy": { "type": "bootstrap" } } The legacy API documentation page <https://thunderbird-webextensions.readthedocs.io/en/latest/legacy.html> has been updated with this information. It also has information on how to link your legacy extension's options page so that Thunderbird can display it on the Tools menu. Thunderbird (version 68 and above) will no longer take any notice of an install.rdf file. The change has enabled the removal of large amounts of code that only existed to support bootstrapped extensions. It will also enable addons.thunderbird.net to do the same, after Thunderbird 60 reaches the end of its supported timeframe. (I realise I may have said that making this change to your extensions was not going to be required, and I don't like to contradict myself, but it's for the best. My apologies!) GL

Questions: 1. I assume this change will land in the 2019-05-20 daily build or the first successful build after 2019-05-20? 2. Previously downloaded and installed bootstrapped extensions without manifest.json will just stop working as of that build, yes? 3. If we upload a fixed version of our add-on to addons.thunderbird.net, will the updated Thunderbird successfully download and install the update, or is updating broken by this change such that every bootstrapped add-on will have to be reinstalled by the user? Thanks,   jik On 5/20/19 4:48 AM, Geoff Lankow wrote: > > In order to simplify things, and to enable addons.thunderbird.net to > receive upgrades much earlier than would otherwise have been possible, > I have changed the way bootstrapped extensions are loaded in Thunderbird. > > They now require a manifest.json file like overlay extensions do, but > with the addition of a "type" attribute on the "legacy" key, like so: > > { > "manifest_version": 2, > .... > "legacy": { > "type": "bootstrap" > } > } > > The legacy API documentation page > <https://thunderbird-webextensions.readthedocs.io/en/latest/legacy.html> > has been updated with this information. It also has information on how > to link your legacy extension's options page so that Thunderbird can > display it on the Tools menu. > > Thunderbird (version 68 and above) will no longer take any notice of > an install.rdf file. > > The change has enabled the removal of large amounts of code that only > existed to support bootstrapped extensions. It will also enable > addons.thunderbird.net to do the same, after Thunderbird 60 reaches > the end of its supported timeframe. > > (I realise I may have said that making this change to your extensions > was not going to be required, and I don't like to contradict myself, > but it's for the best. My apologies!) > > GL > > > _______________________________________________ > Maildev mailing list > Maildev@lists.thunderbird.net > http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net

You may think that the only change extension maintainers need to make as a result of this change is to convert their install.rdf to manifest.json, but alas, that is apparently not the case. I have code in my extension's bootstrap.js that adds new commands to the messageMenuPopup menu. It calls document.getElementById("messageMenuPopup") to get the menu in order to add commands to it. Prior to the 2019-05-20 Thunderbird build (i.e., with install.rdf), this works fine. However, in the 2019-05-20 build it no longer works, because when my add-on is loaded, document.getElementById("messageMenuPopup") returns undefined, i.e., the menu hasn't been created yet. I have confirmed that this is what is happening because when I open a folder in a new window in Thunderbird, the window listener I have configured to add the menu commands in new windows works just fine. But my window listener is not called for the first Thunderbird window; I don't know whether that's because window listeners just aren't called in general for the first window that opens, or because the loading of bootstrapped extensions happens after the listeners for that window have been called. Are we going to treat this change in behavior as a regression that needs to be fixed? If not, can anyone offer any suggestions for what I can do in my bootstrap.js code to cause code to be executed to add the commands to the menu after the window is finished loading, i.e., after the menus are fully created? The code in question is at https://github.com/jikamens/reply-to-multiple-messages/blob/master/bootstrap.js.   jik On 5/20/19 4:48 AM, Geoff Lankow wrote: > > In order to simplify things, and to enable addons.thunderbird.net to > receive upgrades much earlier than would otherwise have been possible, > I have changed the way bootstrapped extensions are loaded in Thunderbird. > > They now require a manifest.json file like overlay extensions do, but > with the addition of a "type" attribute on the "legacy" key, like so: > > { > "manifest_version": 2, > .... > "legacy": { > "type": "bootstrap" > } > } > > The legacy API documentation page > <https://thunderbird-webextensions.readthedocs.io/en/latest/legacy.html> > has been updated with this information. It also has information on how > to link your legacy extension's options page so that Thunderbird can > display it on the Tools menu. > > Thunderbird (version 68 and above) will no longer take any notice of > an install.rdf file. > > The change has enabled the removal of large amounts of code that only > existed to support bootstrapped extensions. It will also enable > addons.thunderbird.net to do the same, after Thunderbird 60 reaches > the end of its supported timeframe. > > (I realise I may have said that making this change to your extensions > was not going to be required, and I don't like to contradict myself, > but it's for the best. My apologies!) > > GL > > > _______________________________________________ > Maildev mailing list > Maildev@lists.thunderbird.net > http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net

N.B. My userChromeJS <https://addons.thunderbird.net/thunderbird/addon/userchromejs-2/> add-on is having the same problem because it ends up loading the user's userChrome.js file before the window has finished loading, which means that the logic in the user's userChrome.js file to look for DOM elements on the window and modify them fails because the elements aren't there yet.   jik On 5/20/19 10:23 AM, Jonathan Kamens wrote: > > You may think that the only change extension maintainers need to make > as a result of this change is to convert their install.rdf to > manifest.json, but alas, that is apparently not the case. > > I have code in my extension's bootstrap.js that adds new commands to > the messageMenuPopup menu. It calls > document.getElementById("messageMenuPopup") to get the menu in order > to add commands to it. Prior to the 2019-05-20 Thunderbird build > (i.e., with install.rdf), this works fine. However, in the 2019-05-20 > build it no longer works, because when my add-on is loaded, > document.getElementById("messageMenuPopup") returns undefined, i.e., > the menu hasn't been created yet. > > I have confirmed that this is what is happening because when I open a > folder in a new window in Thunderbird, the window listener I have > configured to add the menu commands in new windows works just fine. > But my window listener is not called for the first Thunderbird window; > I don't know whether that's because window listeners just aren't > called in general for the first window that opens, or because the > loading of bootstrapped extensions happens after the listeners for > that window have been called. > > Are we going to treat this change in behavior as a regression that > needs to be fixed? > > If not, can anyone offer any suggestions for what I can do in my > bootstrap.js code to cause code to be executed to add the commands to > the menu after the window is finished loading, i.e., after the menus > are fully created? > > The code in question is at > https://github.com/jikamens/reply-to-multiple-messages/blob/master/bootstrap.js. > >   jik > > On 5/20/19 4:48 AM, Geoff Lankow wrote: >> >> In order to simplify things, and to enable addons.thunderbird.net to >> receive upgrades much earlier than would otherwise have been >> possible, I have changed the way bootstrapped extensions are loaded >> in Thunderbird. >> >> They now require a manifest.json file like overlay extensions do, but >> with the addition of a "type" attribute on the "legacy" key, like so: >> >> { >> "manifest_version": 2, >> .... >> "legacy": { >> "type": "bootstrap" >> } >> } >> >> The legacy API documentation page >> <https://thunderbird-webextensions.readthedocs.io/en/latest/legacy.html> >> has been updated with this information. It also has information on >> how to link your legacy extension's options page so that Thunderbird >> can display it on the Tools menu. >> >> Thunderbird (version 68 and above) will no longer take any notice of >> an install.rdf file. >> >> The change has enabled the removal of large amounts of code that only >> existed to support bootstrapped extensions. It will also enable >> addons.thunderbird.net to do the same, after Thunderbird 60 reaches >> the end of its supported timeframe. >> >> (I realise I may have said that making this change to your extensions >> was not going to be required, and I don't like to contradict myself, >> but it's for the best. My apologies!) >> >> GL >> >> >> _______________________________________________ >> Maildev mailing list >> Maildev@lists.thunderbird.net >> http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net

There is an observer that fires, when the window is loaded. Services.obs.addObserver(onLoadObserver, "mail-startup-done", false); I postpone everything and init my AddOn in my onLoadObserver. Hope this helps, John > Am 20.05.2019 um 17:47 schrieb Jonathan Kamens via Maildev <maildev@lists.thunderbird.net>: > > N.B. My userChromeJS add-on is having the same problem because it ends up loading the user's userChrome.js file before the window has finished loading, which means that the logic in the user's userChrome.js file to look for DOM elements on the window and modify them fails because the elements aren't there yet. > > jik > >> On 5/20/19 10:23 AM, Jonathan Kamens wrote: >> You may think that the only change extension maintainers need to make as a result of this change is to convert their install.rdf to manifest.json, but alas, that is apparently not the case. >> >> I have code in my extension's bootstrap.js that adds new commands to the messageMenuPopup menu. It calls document.getElementById("messageMenuPopup") to get the menu in order to add commands to it. Prior to the 2019-05-20 Thunderbird build (i.e., with install.rdf), this works fine. However, in the 2019-05-20 build it no longer works, because when my add-on is loaded, document.getElementById("messageMenuPopup") returns undefined, i.e., the menu hasn't been created yet. >> >> I have confirmed that this is what is happening because when I open a folder in a new window in Thunderbird, the window listener I have configured to add the menu commands in new windows works just fine. But my window listener is not called for the first Thunderbird window; I don't know whether that's because window listeners just aren't called in general for the first window that opens, or because the loading of bootstrapped extensions happens after the listeners for that window have been called. >> >> Are we going to treat this change in behavior as a regression that needs to be fixed? >> >> If not, can anyone offer any suggestions for what I can do in my bootstrap.js code to cause code to be executed to add the commands to the menu after the window is finished loading, i.e., after the menus are fully created? >> >> The code in question is at https://github.com/jikamens/reply-to-multiple-messages/blob/master/bootstrap.js. >> >> jik >> >>> On 5/20/19 4:48 AM, Geoff Lankow wrote: >>> In order to simplify things, and to enable addons.thunderbird.net to receive upgrades much earlier than would otherwise have been possible, I have changed the way bootstrapped extensions are loaded in Thunderbird. >>> >>> They now require a manifest.json file like overlay extensions do, but with the addition of a "type" attribute on the "legacy" key, like so: >>> >>> { >>> "manifest_version": 2, >>> .... >>> "legacy": { >>> "type": "bootstrap" >>> } >>> } >>> The legacy API documentation page has been updated with this information. It also has information on how to link your legacy extension's options page so that Thunderbird can display it on the Tools menu. >>> >>> Thunderbird (version 68 and above) will no longer take any notice of an install.rdf file. >>> >>> The change has enabled the removal of large amounts of code that only existed to support bootstrapped extensions. It will also enable addons.thunderbird.net to do the same, after Thunderbird 60 reaches the end of its supported timeframe. >>> >>> (I realise I may have said that making this change to your extensions was not going to be required, and I don't like to contradict myself, but it's for the best. My apologies!) >>> >>> GL >>> >>> >>> >>> _______________________________________________ >>> Maildev mailing list >>> Maildev@lists.thunderbird.net >>> http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net > _______________________________________________ > Maildev mailing list > Maildev@lists.thunderbird.net > http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net

Another problem which may be a regression caused by this change, or it may be older, I'm not certain (please let me know whether I should open a bug or what)... I call ChromeUtils.import in my bootstrap.js to import a jsm file that is part of my add-on. This call fails immediately after installing the add-on via Install Add-On From File: 1558378623596    addons.xpi    WARN    Exception running bootstrap method startup on reply-to-multiple-messages@kamens.us: [Exception... "File error: Not found"  nsresult: "0x80520012 (NS_ERROR_FILE_NOT_FOUND)"  location: "JS frame :: moz-extension://5bd49a20-36d7-4c37-808c-e136add5ec94/bootstrap.js :: loadDefaultPreferences :: line 626"  data: no] Stack trace: loadDefaultPreferences()@moz-extension://5bd49a20-36d7-4c37-808c-e136add5ec94/bootstrap.js:626 When I exit and restart Thunderbird it works fine on restart.   jik On 5/20/19 4:48 AM, Geoff Lankow wrote: > > In order to simplify things, and to enable addons.thunderbird.net to > receive upgrades much earlier than would otherwise have been possible, > I have changed the way bootstrapped extensions are loaded in Thunderbird. > > They now require a manifest.json file like overlay extensions do, but > with the addition of a "type" attribute on the "legacy" key, like so: > > { > "manifest_version": 2, > .... > "legacy": { > "type": "bootstrap" > } > } > > The legacy API documentation page > <https://thunderbird-webextensions.readthedocs.io/en/latest/legacy.html> > has been updated with this information. It also has information on how > to link your legacy extension's options page so that Thunderbird can > display it on the Tools menu. > > Thunderbird (version 68 and above) will no longer take any notice of > an install.rdf file. > > The change has enabled the removal of large amounts of code that only > existed to support bootstrapped extensions. It will also enable > addons.thunderbird.net to do the same, after Thunderbird 60 reaches > the end of its supported timeframe. > > (I realise I may have said that making this change to your extensions > was not going to be required, and I don't like to contradict myself, > but it's for the best. My apologies!) > > GL > > > _______________________________________________ > Maildev mailing list > Maildev@lists.thunderbird.net > http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net

Thanks. That did it, in combination with loading my stuff into all existing windows in my install() bootstrap method because there are no mail-startup-done events for windows that already exist when the add-on is installed.   jik On 5/20/19 12:55 PM, John Bieling wrote: > There is an observer that fires, when the window is loaded. > > Services.obs.addObserver(onLoadObserver, "mail-startup-done", false); > > I postpone everything and init my AddOn in my onLoadObserver. > > Hope this helps, > John > > Am 20.05.2019 um 17:47 schrieb Jonathan Kamens via Maildev > <maildev@lists.thunderbird.net <mailto:maildev@lists.thunderbird.net>>: > >> N.B. My userChromeJS >> <https://addons.thunderbird.net/thunderbird/addon/userchromejs-2/> >> add-on is having the same problem because it ends up loading the >> user's userChrome.js file before the window has finished loading, >> which means that the logic in the user's userChrome.js file to look >> for DOM elements on the window and modify them fails because the >> elements aren't there yet. >> >>   jik >> >> On 5/20/19 10:23 AM, Jonathan Kamens wrote: >>> >>> You may think that the only change extension maintainers need to >>> make as a result of this change is to convert their install.rdf to >>> manifest.json, but alas, that is apparently not the case. >>> >>> I have code in my extension's bootstrap.js that adds new commands to >>> the messageMenuPopup menu. It calls >>> document.getElementById("messageMenuPopup") to get the menu in order >>> to add commands to it. Prior to the 2019-05-20 Thunderbird build >>> (i.e., with install.rdf), this works fine. However, in the >>> 2019-05-20 build it no longer works, because when my add-on is >>> loaded, document.getElementById("messageMenuPopup") returns >>> undefined, i.e., the menu hasn't been created yet. >>> >>> I have confirmed that this is what is happening because when I open >>> a folder in a new window in Thunderbird, the window listener I have >>> configured to add the menu commands in new windows works just fine. >>> But my window listener is not called for the first Thunderbird >>> window; I don't know whether that's because window listeners just >>> aren't called in general for the first window that opens, or because >>> the loading of bootstrapped extensions happens after the listeners >>> for that window have been called. >>> >>> Are we going to treat this change in behavior as a regression that >>> needs to be fixed? >>> >>> If not, can anyone offer any suggestions for what I can do in my >>> bootstrap.js code to cause code to be executed to add the commands >>> to the menu after the window is finished loading, i.e., after the >>> menus are fully created? >>> >>> The code in question is at >>> https://github.com/jikamens/reply-to-multiple-messages/blob/master/bootstrap.js. >>> >>>   jik >>> >>> On 5/20/19 4:48 AM, Geoff Lankow wrote: >>>> >>>> In order to simplify things, and to enable addons.thunderbird.net >>>> <http://addons.thunderbird.net> to receive upgrades much earlier >>>> than would otherwise have been possible, I have changed the way >>>> bootstrapped extensions are loaded in Thunderbird. >>>> >>>> They now require a manifest.json file like overlay extensions do, >>>> but with the addition of a "type" attribute on the "legacy" key, >>>> like so: >>>> >>>> { >>>> "manifest_version": 2, >>>> .... >>>> "legacy": { >>>> "type": "bootstrap" >>>> } >>>> } >>>> >>>> The legacy API documentation page >>>> <https://thunderbird-webextensions.readthedocs.io/en/latest/legacy.html> >>>> has been updated with this information. It also has information on >>>> how to link your legacy extension's options page so that >>>> Thunderbird can display it on the Tools menu. >>>> >>>> Thunderbird (version 68 and above) will no longer take any notice >>>> of an install.rdf file. >>>> >>>> The change has enabled the removal of large amounts of code that >>>> only existed to support bootstrapped extensions. It will also >>>> enable addons.thunderbird.net <http://addons.thunderbird.net> to do >>>> the same, after Thunderbird 60 reaches the end of its supported >>>> timeframe. >>>> >>>> (I realise I may have said that making this change to your >>>> extensions was not going to be required, and I don't like to >>>> contradict myself, but it's for the best. My apologies!) >>>> >>>> GL >>>> >>>> >>>> _______________________________________________ >>>> Maildev mailing list >>>> Maildev@lists.thunderbird.net >>>> http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net >> _______________________________________________ >> Maildev mailing list >> Maildev@lists.thunderbird.net <mailto:Maildev@lists.thunderbird.net> >> http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net > > _______________________________________________ > Maildev mailing list > Maildev@lists.thunderbird.net > http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net

I've also seen some problems with an extension that adds items to menus. What I've found is that the window has not finished loading when the code runs, so I now check document.readyState, and if it is not "complete", listen for the "load" event. A quick look at your code suggests the same thing would work there. GL On 21/05/19 02:23, Jonathan Kamens via Maildev wrote: > > You may think that the only change extension maintainers need to make > as a result of this change is to convert their install.rdf to > manifest.json, but alas, that is apparently not the case. > > I have code in my extension's bootstrap.js that adds new commands to > the messageMenuPopup menu. It calls > document.getElementById("messageMenuPopup") to get the menu in order > to add commands to it. Prior to the 2019-05-20 Thunderbird build > (i.e., with install.rdf), this works fine. However, in the 2019-05-20 > build it no longer works, because when my add-on is loaded, > document.getElementById("messageMenuPopup") returns undefined, i.e., > the menu hasn't been created yet. > > I have confirmed that this is what is happening because when I open a > folder in a new window in Thunderbird, the window listener I have > configured to add the menu commands in new windows works just fine. > But my window listener is not called for the first Thunderbird window; > I don't know whether that's because window listeners just aren't > called in general for the first window that opens, or because the > loading of bootstrapped extensions happens after the listeners for > that window have been called. > > Are we going to treat this change in behavior as a regression that > needs to be fixed? > > If not, can anyone offer any suggestions for what I can do in my > bootstrap.js code to cause code to be executed to add the commands to > the menu after the window is finished loading, i.e., after the menus > are fully created? > > The code in question is at > https://github.com/jikamens/reply-to-multiple-messages/blob/master/bootstrap.js. > >   jik > > On 5/20/19 4:48 AM, Geoff Lankow wrote: >> >> In order to simplify things, and to enable addons.thunderbird.net to >> receive upgrades much earlier than would otherwise have been >> possible, I have changed the way bootstrapped extensions are loaded >> in Thunderbird. >> >> They now require a manifest.json file like overlay extensions do, but >> with the addition of a "type" attribute on the "legacy" key, like so: >> >> { >> "manifest_version": 2, >> .... >> "legacy": { >> "type": "bootstrap" >> } >> } >> >> The legacy API documentation page >> <https://thunderbird-webextensions.readthedocs.io/en/latest/legacy.html> >> has been updated with this information. It also has information on >> how to link your legacy extension's options page so that Thunderbird >> can display it on the Tools menu. >> >> Thunderbird (version 68 and above) will no longer take any notice of >> an install.rdf file. >> >> The change has enabled the removal of large amounts of code that only >> existed to support bootstrapped extensions. It will also enable >> addons.thunderbird.net to do the same, after Thunderbird 60 reaches >> the end of its supported timeframe. >> >> (I realise I may have said that making this change to your extensions >> was not going to be required, and I don't like to contradict myself, >> but it's for the best. My apologies!) >> >> GL >> >> >> _______________________________________________ >> Maildev mailing list >> Maildev@lists.thunderbird.net >> http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net > > _______________________________________________ > Maildev mailing list > Maildev@lists.thunderbird.net > http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net

My understanding is that this has been part of the typical bootstraped add-on examples, I'm not sure we want to wait for the load event on the Thunderbird side. Shouldn't this be the add-on's task? Philipp > On 22. May 2019, at 1:15 AM, Geoff Lankow <geoff@thunderbird.net> wrote: > > I've also seen some problems with an extension that adds items to menus. What I've found is that the window has not finished loading when the code runs, so I now check document.readyState, and if it is not "complete", listen for the "load" event. A quick look at your code suggests the same thing would work there. > > GL > >> On 21/05/19 02:23, Jonathan Kamens via Maildev wrote: >> You may think that the only change extension maintainers need to make as a result of this change is to convert their install.rdf to manifest.json, but alas, that is apparently not the case. >> >> I have code in my extension's bootstrap.js that adds new commands to the messageMenuPopup menu. It calls document.getElementById("messageMenuPopup") to get the menu in order to add commands to it. Prior to the 2019-05-20 Thunderbird build (i.e., with install.rdf), this works fine. However, in the 2019-05-20 build it no longer works, because when my add-on is loaded, document.getElementById("messageMenuPopup") returns undefined, i.e., the menu hasn't been created yet. >> >> I have confirmed that this is what is happening because when I open a folder in a new window in Thunderbird, the window listener I have configured to add the menu commands in new windows works just fine. But my window listener is not called for the first Thunderbird window; I don't know whether that's because window listeners just aren't called in general for the first window that opens, or because the loading of bootstrapped extensions happens after the listeners for that window have been called. >> >> Are we going to treat this change in behavior as a regression that needs to be fixed? >> >> If not, can anyone offer any suggestions for what I can do in my bootstrap.js code to cause code to be executed to add the commands to the menu after the window is finished loading, i.e., after the menus are fully created? >> >> The code in question is at https://github.com/jikamens/reply-to-multiple-messages/blob/master/bootstrap.js. >> >> jik >> >>> On 5/20/19 4:48 AM, Geoff Lankow wrote: >>> In order to simplify things, and to enable addons.thunderbird.net to receive upgrades much earlier than would otherwise have been possible, I have changed the way bootstrapped extensions are loaded in Thunderbird. >>> >>> They now require a manifest.json file like overlay extensions do, but with the addition of a "type" attribute on the "legacy" key, like so: >>> >>> { >>> "manifest_version": 2, >>> .... >>> "legacy": { >>> "type": "bootstrap" >>> } >>> } >>> The legacy API documentation page has been updated with this information. It also has information on how to link your legacy extension's options page so that Thunderbird can display it on the Tools menu. >>> >>> Thunderbird (version 68 and above) will no longer take any notice of an install.rdf file. >>> >>> The change has enabled the removal of large amounts of code that only existed to support bootstrapped extensions. It will also enable addons.thunderbird.net to do the same, after Thunderbird 60 reaches the end of its supported timeframe. >>> >>> (I realise I may have said that making this change to your extensions was not going to be required, and I don't like to contradict myself, but it's for the best. My apologies!) >>> >>> GL >>> >>> >>> >>> _______________________________________________ >>> Maildev mailing list >>> Maildev@lists.thunderbird.net >>> http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net >> >> >> _______________________________________________ >> Maildev mailing list >> Maildev@lists.thunderbird.net >> http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net > _______________________________________________ > Maildev mailing list > Maildev@lists.thunderbird.net > http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net