1596481 - Should be able to update extension via policy

Status: RESOLVED FIXED

(Firefox :: Enterprise Policies, enhancement, P3)

Description

[Mike Kaply [:mkaply]]

Right now if the ExtensionSettings policy installs an addon, it never reinstalls it, so you can't update locally.

Need to figure out a way around that.

Chrome does this by having you give the URL to the update service not the XPI and then it can check what the correct version is.

We might end up having to download the XPI and check the version.

Or maybe we should put the version in ExtensionSettings and when that is different than the current version, update?

Comment 1

[per.malmberg]

Please allow for updates of extensions that are not distributed via an URL, i.e. only as a local file.

In the case the where the install_url is of the form file://... it'd be really great if FF could compare the version of the referenced XPI to the one currently install and if newer (or even just different) install the referenced one.

Having the version in the ExtensionSettings makes no sense when the XPI is available as it already contains the version. As such, I'd prefer to see two different behaviours:

1. Local XPI via file:/.... - FF compares the version directly from the XPI.
2. Via an actual web URL - FF downloads the XPI to check the version.

How does FF handle updates of extensions installed by the user? Can that method be used for number two?

Comment 2

[Mike Kaply [:mkaply]]

The problem is we'd have to download the XPI every time the browser is started.

How does FF handle updates of extensions installed by the user? Can that method be used for number two?

It grabs an update URL and checks the version there, but we don't have the update URL (and it wouldn't matter really because we'd still have to handle the case where a XPI didn't have an update URL.

I'm trying to avoid storing any persistent data about the previous XPI that was installed.

For now, I might just build the download/check version case and folks will just have to deal with the extra work at startup.

Comment 3

[per.malmberg]

I can understand the desire avoid storing persistent data, but in the case if a local XPI that's not a problem, is it?

For the second case, how about allowing the policy to set a time interval or perhaps a list of days on which the update should happen? That would reduce the amount of work done on start up and also reduce the amount of data downloaded for possibly no use. Yes, you'd have to store the last time the update ran, and clear it on uninstall and also check if a check has been missed, but it gives some control over the updates.

Comment 4

[sixtyten]

This is kind of a showstopper for me. I am also migrating a sideloaded extension but finding no way to update it. There is no automatic update check at browser startup, chrome.runtime.requestUpdateCheck() is not implemented in Firefox, and even explicitly checking for updates from about:addons does not change anything. I have a very, very dirty workaround, but it relies on a bug elsewhere and is not guaranteed to keep working, and is also bad UX.

As for ways to implement this - shouldn't it be possible to skip the download+unpack most of the time if the XPI's timestamp. size and/or (in HTTP's case) ETags and other caching attributes didn't change? Or is even the XPI itself not stored?

Comment 5

[Mike Kaply [:mkaply]]

This is still on my radar, got sidetracked.

Did you put an update_url in your extension and put an update manifest on your server?

https://extensionworkshop.com/documentation/manage/updating-your-extension/

Comment 6

[sixtyten]

No, I have a signed-by-mozilla but unlisted extension and the install_url points to a file:// link. But nothing is preventing me from storing an update manifest on the filesystem (I already store the xpi and a native messaging manifest there), so if making updates work is just a matter of an additional json file, then that'd work for me.

Comment 7

[Mike Kaply [:mkaply]]

No, I have a signed-by-mozilla but unlisted extension and the install_url points to a file:// link. But nothing is preventing me from storing an update manifest on the filesystem (I already store the xpi and a native messaging manifest there), so if making updates work is just a matter of an additional json file, then that'd work for me.

I've never tried updates from a file URL, so I have no idea if that would work. My first instinct is no, but we'd need to test.

Comment 8

[per.malmberg]

(In reply to Mike Kaply [:mkaply] from comment #7)

I've never tried updates from a file URL, so I have no idea if that would work. My first instinct is no, but we'd need to test.

And just to iterate, that needs to work; we've got a million installations using this method by now. The expectation here is that simply replacing the XPI will result in an upgrade/downgrade of the expectation.

Comment 9

[per.malmberg]

upgrade/downgrade of the expectation.

upgrade/downgrade of the extension.

(can't edit posts)

Comment 10

[Mike Kaply [:mkaply]]

I'm working on this now and had a question. Would a requirement that the extension source URL be too onerous to require an update?

(This would probably only apply to extensions on the web, not addons installed via file URLs. still researching).

Comment 11

[Mike Kaply [:mkaply]]

Attachment: Bug 1596481 - Try to update extensions installed via policy. r?mixedpuppy

Comment 12

[per.malmberg]

Mike,

I'm guessing you you accidentally lost the word, "change" in your question?

Yes, I'd say requiring the update URL to change in order to trigger an update is onerous. If required, it goes from a one-step to two-step process; first update the actual XPI on the server, then update each local client to trigger the update. I'd much prefer it to be a one-step process, this is also more in line with how extensions from the regular store are updated. The same reasoning goes for file://-urls; change the XPI and FF does the rest.

I know for a fact that companies with strict change management would greatly appreciate being able to update and extension without having to make changes to each individual computer when hosting XPIs on an internal server.

Comment 13

[Mike Kaply [:mkaply]]

Most extensions already have the ability to update themselves with update_urls and manifests. I don't think it makes sense to reinvent that.

I think the primary thing that needs to be addressed here is local file updates (which I'm solving). And I'm adding in the URL comparison to help in other situations.

If you are serving a custom extension via https, you should have an update URL in that extension and you should have an update manifest and that's how the extension should get updated.

I can't download the extension from the web at every startup and check if there is a new version - that's just not feasible. I could download an update manifest, but that assumes the extension already has one. which means there's no need for me to download it, just allow the extension to update itself.

Chrome solves this by having the install link for the extension be the update manifest, not the actual extension. I'll investigate doing that in the future, but it would still involving basically having an update manifest somewhere.

Comment 14

[per.malmberg]

Ah, yes. You're completely right.

Comment 15

[Mike Kaply [:mkaply]]

But I think to better handle your usecase, I should have the install_url link as well and use that to get updates via policy if for some reason that aren't available in the extension. Covers all bases.

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/cd9a71d12e7d
Try to update extensions installed via policy. r=mixedpuppy

Comment 17

[Cristian Brindusan [:cbrindusan]]

https://hg.mozilla.org/mozilla-central/rev/cd9a71d12e7d