Firefox 43.0.3 installs extension OK but disables it later

Add-ons Development
#1

Several users of my signed Firefox extension have complained to me that, after successfully installing the extension by opening the .xpi file with Firefox and clicking Install, at some point, maybe hours or days later, Tools > Add-Ons > Extensions will indicate that my extension has been disabled.

Of course, this is expected behavior if someone went into the profile folder and tinkered with it, but I have no reason to believe that is happening.

My extension ships as a .xpi file in my native OS X app and is not listed in addons.mozilla.org. In case anyone wants to download and have a look, I’ve put it in my Dropbox Public Folder

Is this a known or becoming-known issue?

#2

More information. One user tells me that Firefox disables it after four or five launches. I asked him to go into his profile folder after this happened, zip up the folder containing my extension, and send it to me. He did so. When I received it, I quit Firefox 43.0.3 on my Mac, went into my profile folder, and replaced my syncextension@sheepsystems.com folder with the one I had unzipped from him. Then I launched Firefox, visited Tools > Add-Ons, and my extension was there, enabled. I did this six more times, and each time it was fine.

So this indicates that the extension was not tampered with, and Firefox should not have disabled it.

How can we troubleshoot this issue?

#3

It’s possible that something changed in the folder that is breaking the signature. One possibility is that the user opened the folder in the Finder, which can sometimes creates hidden files in it. It’s usually best to keep the file compressed to avoid this problem, but I don’t remember if that was supported for global installs.

Also, it would be good that you give us a link to the add-on page (I know it’s unlisted), so we can look into its signature.

#4

Thank you, Jorge.

Regarding opening the folder in Finder, you mean for example those pesky .DS_Store files. I just did an experiment and found that the zip compression utility in OS X does include .DS_Store files when it creates a zip archive. So if there was one in this user’s extension, it should have prevented the extension from loading on my computer too, but it did not.

It’s something to think about, though. How would I keep my extension compressed? I mean, Firefox apparently decided to decompress it during the installation. How can I prevent that?

My first post contained a link to my firefox extension, so you can look into its signature. Is that good enough? That’s what I’m packaging into my app.

#5

Correction. I goofed this morning. I’d mistake my developer-edition-default profile folder with my default profile folder. The truth is that when I replace my syncextension@sheepsystems.com folder in Profiles/xxxxxxxx.default/extensions with the failing folder from this user, and relaunch Firefox, Firefox disables it for me too.

There’s more. The short answer is that the problem is the stupid .DS_Store files, as Jorge suggested.

Longer answer: User told me after reading Jorge’s post that he runs a script on his Mac that remove .DS_Store files every hour!! Also, I asked him a couple days ago to look inside the installed extension and inside the META-INF folder to make sure the signatures were in there. Finally, I noticed that the extensions I ship, unfortunately, contain one .DS_Store file, inside the ‘chrome’ subfolder. Now, when I compare the extension as initially installed with the extension he sent me, there are three differences: (1) He has an extra .DS_Store file in the root level, (2) He has an extra .DS_Store file in META-INF and (3) He has a missing .DS_Store file in the ‘chrome’ subfolder. If you’ve been following everything I said so far, you’ll realize that it all adds up. I think this issue is now understood and resolved.

Conclusions:

  1. I should review my extension packing script to ensure that I have no .DS_Store files anywhere. (I think that this is recommended in the documentation anyhow.)

  2. Scripts that remove .DS_Store files are not only silly but evil.

  3. Jorge, please tell me if there is a way to change my extension so that Firefox will not unzip it during installation, as you suggested.

#6

See https://developer.mozilla.org/en-US/Add-ons/Install_Manifests#unpack

#7

Thank you, Andreas.

#9

I’m replying to kebnab.

The reason why you never had a problem before is because Firefox did not checking signatures until, I think, Firefox 43.

There are six reasons why your extension might not work AT ALL if you turn off unpack. These are listed in the documentation linked to by Andreas Wagner above. In my case, it looks like I need to have unpack because my extension contains an OS X .dylib (Apple’s name for a dynamically linked library DLL) with ctypes.