I am testing an unsigned .xpi in Firefox ESR at the moment. For some reason on first install of a newly zipped .xpi my code doesn’t recognize the install and hence doesn’t run the block with the details.reason === ‘install’ check.
Here’s the code block

function handleStorageDefaults(details) {
	const temp = details.temporary;
	const install = (details.reason === 'install');
	const update = (details.reason === 'update');
	if (temp || install || update) {
		/* Construct storage object */
		const keys = {
			alarm: '18:30:00',
			filename: '',
			bulkReload: 5,
			reoccur: true,
			append: true
		/* Clear browser storage first on install or temp install or
		   update */
		.then(() => console.log(`Storage cleared`),
			error => console.error(error));
		.then(() =>
				/* Set defaults on localStorage object */
				console.log('Storage defaults set');
				/* Set default alarm for 6:30PM */
			error => console.error(error)

Any help would be appreciated as to why the if block won’t run on first install. Thanks.

1 Like

Are you registering the handler on the top level of the background script?
And does it work for update? Or during the development?

Thanks for your reply. Yes I have the handler registered on the top level of the background script.


The function works during temporary install while developing and also works for update (if I uninstall and reinstall the same .xpi without rezipping it or changing the version in manifest.json). It just doesn’t work on the first install from a newly zipped file. So it seems that only the

details.reason === 'install';

isn’t working. Additionally, this seems very difficult to tackle using the debugger because how do you set a breakpoint or a watch on an extension before it’s first install so I could see the value of the details.reason variable right then.

You could log it to the console.
Assuming that Firefox actually calls the handler.

And there’s the debugger statement in Javascript.
But I don’t know if it invokes the FF debugger when used in an extension.

This is what I’ve narrowed it down to:

Upon installation of the add on I am prompted at the permissions dialogue and I select “Add”. Then there is a second dialogue confirming that the add on was installed and prompting me with a checkbox “Allow this extension to run in Private Windows”. If I change the options (check or uncheck the box) my add on does not run the handler and my defaults aren’t set. If I go ahead and click “Okay” without touching the box (leaving it on it’s preselection whether checked or unchecked), my add on does run the handler and my defaults are set.

Any assistance resolving this behavior would be appreciated. Obviously I want the handler to run every time, no matter if I select to run in private windows or not upon install. Thanks.

Isn’t the handler running right after confirming the permissions dialog? I mean before the “Private Windows” popup appears.

The issue with the Private Windows popup is a known bug, but I can’t find the relevant link now. From what I remember, when you check the checkbox that you want to allow it to run in private windows, the addon is reloaded! And as you know, reloading addon has some consequences, like all addon pages are closed, that’s what the issue (I can’t find now) was about, that any on-boarding page that addon opens during installation is closed once you approve Private mode.

Found it:

Still, the event should still fire and setup your persistent storage.