onUnload() bug?

I am writing an addon these days, and I found some strange and unexpected behavior regarding onUnload() function.
My addon is updating the Home page URL upon install, and reverts that URL when the user removes or disables the addon.

But I noticed that when I remove + use “Undo” multiple times, the function onUnload() is never reached again.

My onUnload() function is added to the exports, and is correctly called most of the time. I think that upon “disable” or “remove” command in about:addons, the onUnload() function should automatically be called? But according to my logging, it seems it is not always the case.

Thanks for your patience of 5 days on this question.

This isn’t a bug. From the addon manager, on a restartless addon, when you click “Remove” it is marked as “Soft Uninstalled”. This means that you can still click “Undo” and it will “un-remove” the addon. If you don’t click “Undo” and when you close the addon manager or navigate to another page in the addon manager, then it triggers the hard uninstall, which will trigger your unload.

Try it out, you should find that it works like that.

Hello noitidart, thank you for your feedback.
I maintain that this seems to be a bug.

You say that when I “remove” and close the window, it should execute the “onUnload()” function? It doesn’t. It doesn’t when I have played around with remove/undo/remove/undo/disable/undo.

By the time I actually do my last “remove” and close the window, it doesn’t execute onUnload().
So whatever action I need to execute there, doesn’t get executed.

Here is my code

Unpon install, I execute this:
_extGlobal.prefService.set(extGlobal.constants.distributionChannelPrefKey, distribution_channel);

And here is my onUnload function
exports.onUnload = function (reason){ //jshint ignore: line
if(reason === ‘disable’ || reason === ‘uninstall’)
{
extGlobal.prefService.reset(extGlobal.constants.distributionChannelPrefKey); //removing the distribution channel value
}
};

When I delete my addon, close my browser, restart it, I can go into about:config and I can see that the key is still here, it was not deleted at all.
It works when I disable/remove once. But playing around with “undo” will result in not going to onUnload() function anymore, which means the value remains in about:config even after the addon is deleted.

It’s good of you to clean up after your addon.

I’m not so familiar with the SDK so I really can’t say much.

But from bootstrap addons you can do this in the shutdown and uinstall procs.

Hopefully someone familiar with SDK can respond.

Can you try putting a try/catch block around that code and use console.log to display the error message in the console? Maybe an exception is swallowed, which would explain why the preference continues to exist.

Hi, thanks for your suggestion. I tried this and really, the “onUnload()” function executes once only…

Scenario:
I have an addon.

  1. I click on “Remove” >> The onUnload function is correctly called. My preference variables are successfully deleted
  2. I do “undo” >> The loading (installing) starts again, and it sets the preference variables and do all kind of things
  3. I do “Remove” again >> The onUnload is not called, my preference variables will never be deleted after this.

The behavior is the same if I do “disable” instead of “remove” on the above steps.