Hi, I'm working on porting the Dorando Keyconfig extension to Thunderbird 68. I volunteered to sort of act as a co-custodian of this extension a while back, i.e., upgrading it to support new TB versions but not doing any work on it other than that. Until now the lifting for that has been pretty light, but I suspect the TB 68 upgrade is going to be more burdensome. :-/ Because I didn't write this code and have only worked on it minimally since I started to help maintaining it. I am not terribly familiar with the code. Shortly after diving in to attempting to upgrade it for TB 68, I found this in chrome.manifest: component {e9f7950e-d78d-4aaa-900a-c43588052eba} components/keyconfig-service.js contract @dorando.at/keyconfig;1 {e9f7950e-d78d-4aaa-900a-c43588052eba} category profile-after-change keyconfigService @dorando.at/keyconfig;1 I've never done anything with these types of directives in chrome.manifest before, so I don't have a good understanding of what they do or how they do it. I have a vague recollection of perhaps reading somewhere that this is no longer supported in TB 68, but looking at the documentation now I can't find that, so either I'm being dense now or I imagined the whole thing. Can somebody help me out by (a) explaining at a high level what the lines above due in earlier TB versions, (b) confirm or refute my suspicion that they're no longer gong to work with a legacy add-on in TB 68, and (c) if so, suggest an alternative way to do the same thing in TB68? This is the file that's referenced above: https://github.com/trlkly/dorando-keyconfig/blob/master/components/keyconfig-service.js Thanks, jik

I am not an expert at this, and your component's code is a few refactorings older than I'm used to, but here's what I think anyway: Your chrome.manifest code /should/ all still be working. Briefly what it does is register the Factory object in keyconfig-service.js as Components.classes["@dorando.at/keyconfig;1"]. The category line adds it to the profile-after-change category, so it receives the profile-after-change observer notification at the appropriate time. I can't actually see your component handling this, so maybe it's obsolete? (Side note 1: There are other categories that do vastly different things. This one just happens to send a notification.) (Side note 2: When the overlay loader was rebuilt the notification was one of the things we had to reimplement, since extensions are now loaded later in the scheme of things.) This is a useful page about components <https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Guide/Building_components_in_JavaScript>. It's about the same vintage as your code so should be useful to help understand it. This is a page about chrome registration <https://developer.mozilla.org/en-US/docs/Mozilla/Chrome_Registration#component>. Some bits of it are obsolete (most notably interfaces and binary-component) so I've linked straight to the useful bit. Hope that helps! GL On 1/04/19 03:45, Jonathan Kamens via Maildev wrote: > > Hi, > > I'm working on porting the Dorando Keyconfig extension to Thunderbird > 68. I volunteered to sort of act as a co-custodian of this extension a > while back, i.e., upgrading it to support new TB versions but not > doing any work on it other than that. Until now the lifting for that > has been pretty light, but I suspect the TB 68 upgrade is going to be > more burdensome. :-/ > > Because I didn't write this code and have only worked on it minimally > since I started to help maintaining it. I am not terribly familiar > with the code. Shortly after diving in to attempting to upgrade it for > TB 68, I found this in chrome.manifest: > > component {e9f7950e-d78d-4aaa-900a-c43588052eba} components/keyconfig-service.js > contract @dorando.at/keyconfig;1 {e9f7950e-d78d-4aaa-900a-c43588052eba} > category profile-after-change keyconfigService @dorando.at/keyconfig;1 > > I've never done anything with these types of directives in > chrome.manifest before, so I don't have a good understanding of what > they do or how they do it. I have a vague recollection of perhaps > reading somewhere that this is no longer supported in TB 68, but > looking at the documentation now I can't find that, so either I'm > being dense now or I imagined the whole thing. > > Can somebody help me out by (a) explaining at a high level what the > lines above due in earlier TB versions, (b) confirm or refute my > suspicion that they're no longer gong to work with a legacy add-on in > TB 68, and (c) if so, suggest an alternative way to do the same thing > in TB68? > > This is the file that's referenced above: > https://github.com/trlkly/dorando-keyconfig/blob/master/components/keyconfig-service.js > > Thanks, > > jik > > > > _______________________________________________ > Maildev mailing list > Maildev@lists.thunderbird.net > http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net

Oh, now I see it, you don't need to handle the notification, it's just used to make keyconfigService run at the appropriate time. Here's Lightning doing the same thing. <https://searchfox.org/comm-central/rev/f60c9cd255fe16c7a583212de070a953f41e709d/calendar/base/backend/calBackendLoader.js> As you can see a lot of the boilerplate has been refactored away over the years. (Just ignore the loadBackend and lazyFactoryFor functions, they're not part of my point.) GL On 1/04/19 15:00, Geoff Lankow wrote: > > I am not an expert at this, and your component's code is a few > refactorings older than I'm used to, but here's what I think anyway: > > Your chrome.manifest code /should/ all still be working. Briefly what > it does is register the Factory object in keyconfig-service.js as > Components.classes["@dorando.at/keyconfig;1"]. The category line adds > it to the profile-after-change category, so it receives the > profile-after-change observer notification at the appropriate time. I > can't actually see your component handling this, so maybe it's obsolete? > > (Side note 1: There are other categories that do vastly different > things. This one just happens to send a notification.) > > (Side note 2: When the overlay loader was rebuilt the notification was > one of the things we had to reimplement, since extensions are now > loaded later in the scheme of things.) > > This is a useful page about components > <https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Guide/Building_components_in_JavaScript>. > It's about the same vintage as your code so should be useful to help > understand it. > > This is a page about chrome registration > <https://developer.mozilla.org/en-US/docs/Mozilla/Chrome_Registration#component>. > Some bits of it are obsolete (most notably interfaces and > binary-component) so I've linked straight to the useful bit. > > Hope that helps! > > GL > > On 1/04/19 03:45, Jonathan Kamens via Maildev wrote: >> >> Hi, >> >> I'm working on porting the Dorando Keyconfig extension to Thunderbird >> 68. I volunteered to sort of act as a co-custodian of this extension >> a while back, i.e., upgrading it to support new TB versions but not >> doing any work on it other than that. Until now the lifting for that >> has been pretty light, but I suspect the TB 68 upgrade is going to be >> more burdensome. :-/ >> >> Because I didn't write this code and have only worked on it minimally >> since I started to help maintaining it. I am not terribly familiar >> with the code. Shortly after diving in to attempting to upgrade it >> for TB 68, I found this in chrome.manifest: >> >> component {e9f7950e-d78d-4aaa-900a-c43588052eba} components/keyconfig-service.js >> contract @dorando.at/keyconfig;1 {e9f7950e-d78d-4aaa-900a-c43588052eba} >> category profile-after-change keyconfigService @dorando.at/keyconfig;1 >> >> I've never done anything with these types of directives in >> chrome.manifest before, so I don't have a good understanding of what >> they do or how they do it. I have a vague recollection of perhaps >> reading somewhere that this is no longer supported in TB 68, but >> looking at the documentation now I can't find that, so either I'm >> being dense now or I imagined the whole thing. >> >> Can somebody help me out by (a) explaining at a high level what the >> lines above due in earlier TB versions, (b) confirm or refute my >> suspicion that they're no longer gong to work with a legacy add-on in >> TB 68, and (c) if so, suggest an alternative way to do the same thing >> in TB68? >> >> This is the file that's referenced above: >> https://github.com/trlkly/dorando-keyconfig/blob/master/components/keyconfig-service.js >> >> Thanks, >> >> jik >> >> >> >> _______________________________________________ >> 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

Thanks for the info. I'm still a bit confused, but it looks to me like maybe I can just get rid of the component completely and just convert the add-on to bootstrapped, because then the code that is currently running in the keyconfig "service" can just be instantiated in `startup` in bootstrap.js?   jik On 3/31/19 10:12 PM, Geoff Lankow wrote: > > Oh, now I see it, you don't need to handle the notification, it's just > used to make keyconfigService run at the appropriate time. Here's > Lightning doing the same thing. > <https://searchfox.org/comm-central/rev/f60c9cd255fe16c7a583212de070a953f41e709d/calendar/base/backend/calBackendLoader.js> > As you can see a lot of the boilerplate has been refactored away over > the years. (Just ignore the loadBackend and lazyFactoryFor functions, > they're not part of my point.) > > GL > > On 1/04/19 15:00, Geoff Lankow wrote: >> >> I am not an expert at this, and your component's code is a few >> refactorings older than I'm used to, but here's what I think anyway: >> >> Your chrome.manifest code /should/ all still be working. Briefly what >> it does is register the Factory object in keyconfig-service.js as >> Components.classes["@dorando.at/keyconfig;1"]. The category line adds >> it to the profile-after-change category, so it receives the >> profile-after-change observer notification at the appropriate time. I >> can't actually see your component handling this, so maybe it's obsolete? >> >> (Side note 1: There are other categories that do vastly different >> things. This one just happens to send a notification.) >> >> (Side note 2: When the overlay loader was rebuilt the notification >> was one of the things we had to reimplement, since extensions are now >> loaded later in the scheme of things.) >> >> This is a useful page about components >> <https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Guide/Building_components_in_JavaScript>. >> It's about the same vintage as your code so should be useful to help >> understand it. >> >> This is a page about chrome registration >> <https://developer.mozilla.org/en-US/docs/Mozilla/Chrome_Registration#component>. >> Some bits of it are obsolete (most notably interfaces and >> binary-component) so I've linked straight to the useful bit. >> >> Hope that helps! >> >> GL >> >> On 1/04/19 03:45, Jonathan Kamens via Maildev wrote: >>> >>> Hi, >>> >>> I'm working on porting the Dorando Keyconfig extension to >>> Thunderbird 68. I volunteered to sort of act as a co-custodian of >>> this extension a while back, i.e., upgrading it to support new TB >>> versions but not doing any work on it other than that. Until now the >>> lifting for that has been pretty light, but I suspect the TB 68 >>> upgrade is going to be more burdensome. :-/ >>> >>> Because I didn't write this code and have only worked on it >>> minimally since I started to help maintaining it. I am not terribly >>> familiar with the code. Shortly after diving in to attempting to >>> upgrade it for TB 68, I found this in chrome.manifest: >>> >>> component {e9f7950e-d78d-4aaa-900a-c43588052eba} components/keyconfig-service.js >>> contract @dorando.at/keyconfig;1 {e9f7950e-d78d-4aaa-900a-c43588052eba} >>> category profile-after-change keyconfigService @dorando.at/keyconfig;1 >>> >>> I've never done anything with these types of directives in >>> chrome.manifest before, so I don't have a good understanding of what >>> they do or how they do it. I have a vague recollection of perhaps >>> reading somewhere that this is no longer supported in TB 68, but >>> looking at the documentation now I can't find that, so either I'm >>> being dense now or I imagined the whole thing. >>> >>> Can somebody help me out by (a) explaining at a high level what the >>> lines above due in earlier TB versions, (b) confirm or refute my >>> suspicion that they're no longer gong to work with a legacy add-on >>> in TB 68, and (c) if so, suggest an alternative way to do the same >>> thing in TB68? >>> >>> This is the file that's referenced above: >>> https://github.com/trlkly/dorando-keyconfig/blob/master/components/keyconfig-service.js >>> >>> Thanks, >>> >>> jik >>> >>> >>> >>> _______________________________________________ >>> 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

Unfortunately I think I'm going to have to defer this; I've spent all the time I can spare upgrading addons to TB68 for the time being. I find the Keyconfig code difficult to work with, and I think at this point it has suffered enough entropy and bitrot that what's really needed is to rewrite the whole thing from scratch as a bootstrapped add-on. I unfortunately don't have the time for that right now. If somebody else feels like taking it on, feel free to submit a PR at https://github.com/trlkly/dorando-keyconfig/.   jik On 4/1/19 7:13 AM, Jonathan Kamens wrote: > > Thanks for the info. I'm still a bit confused, but it looks to me like > maybe I can just get rid of the component completely and just convert > the add-on to bootstrapped, because then the code that is currently > running in the keyconfig "service" can just be instantiated in > `startup` in bootstrap.js? > >   jik > > On 3/31/19 10:12 PM, Geoff Lankow wrote: >> >> Oh, now I see it, you don't need to handle the notification, it's >> just used to make keyconfigService run at the appropriate time. >> Here's Lightning doing the same thing. >> <https://searchfox.org/comm-central/rev/f60c9cd255fe16c7a583212de070a953f41e709d/calendar/base/backend/calBackendLoader.js> >> As you can see a lot of the boilerplate has been refactored away over >> the years. (Just ignore the loadBackend and lazyFactoryFor functions, >> they're not part of my point.) >> >> GL >> >> On 1/04/19 15:00, Geoff Lankow wrote: >>> >>> I am not an expert at this, and your component's code is a few >>> refactorings older than I'm used to, but here's what I think anyway: >>> >>> Your chrome.manifest code /should/ all still be working. Briefly >>> what it does is register the Factory object in keyconfig-service.js >>> as Components.classes["@dorando.at/keyconfig;1"]. The category line >>> adds it to the profile-after-change category, so it receives the >>> profile-after-change observer notification at the appropriate time. >>> I can't actually see your component handling this, so maybe it's >>> obsolete? >>> >>> (Side note 1: There are other categories that do vastly different >>> things. This one just happens to send a notification.) >>> >>> (Side note 2: When the overlay loader was rebuilt the notification >>> was one of the things we had to reimplement, since extensions are >>> now loaded later in the scheme of things.) >>> >>> This is a useful page about components >>> <https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Guide/Building_components_in_JavaScript>. >>> It's about the same vintage as your code so should be useful to help >>> understand it. >>> >>> This is a page about chrome registration >>> <https://developer.mozilla.org/en-US/docs/Mozilla/Chrome_Registration#component>. >>> Some bits of it are obsolete (most notably interfaces and >>> binary-component) so I've linked straight to the useful bit. >>> >>> Hope that helps! >>> >>> GL >>> >>> On 1/04/19 03:45, Jonathan Kamens via Maildev wrote: >>>> >>>> Hi, >>>> >>>> I'm working on porting the Dorando Keyconfig extension to >>>> Thunderbird 68. I volunteered to sort of act as a co-custodian of >>>> this extension a while back, i.e., upgrading it to support new TB >>>> versions but not doing any work on it other than that. Until now >>>> the lifting for that has been pretty light, but I suspect the TB 68 >>>> upgrade is going to be more burdensome. :-/ >>>> >>>> Because I didn't write this code and have only worked on it >>>> minimally since I started to help maintaining it. I am not terribly >>>> familiar with the code. Shortly after diving in to attempting to >>>> upgrade it for TB 68, I found this in chrome.manifest: >>>> >>>> component {e9f7950e-d78d-4aaa-900a-c43588052eba} components/keyconfig-service.js >>>> contract @dorando.at/keyconfig;1 {e9f7950e-d78d-4aaa-900a-c43588052eba} >>>> category profile-after-change keyconfigService @dorando.at/keyconfig;1 >>>> >>>> I've never done anything with these types of directives in >>>> chrome.manifest before, so I don't have a good understanding of >>>> what they do or how they do it. I have a vague recollection of >>>> perhaps reading somewhere that this is no longer supported in TB >>>> 68, but looking at the documentation now I can't find that, so >>>> either I'm being dense now or I imagined the whole thing. >>>> >>>> Can somebody help me out by (a) explaining at a high level what the >>>> lines above due in earlier TB versions, (b) confirm or refute my >>>> suspicion that they're no longer gong to work with a legacy add-on >>>> in TB 68, and (c) if so, suggest an alternative way to do the same >>>> thing in TB68? >>>> >>>> This is the file that's referenced above: >>>> https://github.com/trlkly/dorando-keyconfig/blob/master/components/keyconfig-service.js >>>> >>>> Thanks, >>>> >>>> jik >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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