Natively Installed Extensions DO Auto Update (Doc is wrong?)

Add-ons Development
#1

Native applications (or users) can install extensions into Firefox by simply copying them into certain folders, as described in this document. (I call this the hot folder method of extension installation.) In that document, it is stated that:

No automatic updates will be performed for extensions installed in this way. Since the extension’s files are installed by an native tool, the application expects the native tool to handle performing updates.

I just tested this and found differently, that automatic updates are performed for extensions installed in this way. Steps to reproduce (in macOS 10.12)

  • Remove prior installations of my extensions. (They are WebExtensions.)
  • Relaunch Firefox twice, to ensure it has completely forgotten them.
  • Reinstall my two extensions using the hot folder method. Specifically, I copied the two signed .xpi files to:
    ~/Library/Application Support/Firefox/Profiles/xxxxxxxx.default/extensions/
  • Relaunch Firefox and approve the two installations.
  • Uploaded updates of these two extensions to my server and indicated them in the associated update manifest.

Expected Result (based on that document): Updates should not occur.

Actual Result: After a couple hours and more relaunches (it seems caches needed to clear), my two Firefox extensions were updated.

Can someone please confirm that this document and not the behavior is wrong? I really like the behavior the way it is. If my native tool did the updating, user would probably be asked to approve the installation of each update on the next Firefox relaunch, which would be annoying. Also, the other method of natively installing an extension (opening a .xpi file), although obvious, is not documented anywhere that I know of, and sometimes doesn’t work because the popover which should ask the user’s approval does not always appear.

(By the way, until yesterday the quoted paragraph was in small Note. I moved it to a separate paragraph and marked it as Important because, if it were true, it would be quite important.)

1 Like
#2

As I understand it, the documentation should be correct and sideloaded add-ons can’t auto-update. Maybe @Mossop can confirm?

#3

Thank you, Jorge. I have tried it several more times in the last two days, one on a virgin profile, and it always works. My extensions loaded in this way gets auto-updated from my secure server.

I should point out that, after copying to the hot folder, the extension does not load until the next time Firefox launches, and the user approves of the installation. As I recall, back in the old days, maybe three years ago, that did not occur; side-loaded extensions loaded without the user ever having to approve. Possibly when the change was made to require user approval, auto-updating was added as an intended or unintended side effect. Either way, the current behavior is logical, secure, gives a great user experience, and I hope this is not viewed as a bug.

#4

Add-ons installed in the profile folder do get auto-updated, but native applications should not be installing extensions into the profile folder.

#5

Why not, Dave? The documentation stated that this was a supported method in Windows, so I tried it in macOS and found that it works in macOS too.

Often, a native app wants the user to install an extension in only one profile.

The only other way to do this is to (1) ask the user to run Firefox in the desired profile and then (2) open the .xpi file. The system open handler sends it to Firefox, which should then present a little popover asking for approval. This method is much less reliable because (1) it is difficult for users to verify what profile Firefox is currently running in and (2) at least in macOS, the popover often either fails to appear, or disappears before the user can click it, and (3) sometimes the same popover reappears, asking for the same approval, on the relaunch, so it takes two or three relaunches.

If the native app copies it to the extensions subfolder of the profile folder as I have been testing, the approval appears only once per extension, in a tab, in a very large font so the user realizes this is important, and it always works the first time.

#6

Uh, you changed some of the documentation, and I think you made a mistake there. But I’m not sure.

From what I recall, there are tow ways for an extension to be installed:

  • inside the ./extensions/ subdirectoy of the current profile
  • in different global folders

The former update automatically, while the latter are expected to be updated by, depending on the exact folder, either native applications or when the browser is updated.

If you are dumping your extension in the ./extensions/ subdirectoy of the current profile, you are opting for automatic updates. (And because the profile also has list of the extensions and their versions that are supposed to be in there, Firefox will ask the user to confirm any changes.)

What the documentation was talking about were the “global folders”, those are intended to not update automatically, for several good reasons. So I’m pretty sure the documentation was correct.

#7

Thank you, @NilkasG. I see what happened now. Before I edited the document, it gave three installation alternatives for Windows, one of them being ProfileFolder\extensions. I found that this alternative worked in macOS too, and so added a similar alternative for macOS. And this was the only method I tested for auto-updating.

@Mossop edited the document yesterday, removing both of these alternatives, the original one regarding Windows, and mine regarding macOS, but leaving the note that auto updates will not occur.

So now, the document only covers installing into what you call the “global folders”, and I presume you are correct that auto updates will not occur. With this limitation of its scope, the document is now correct.