External extensions and update_url

[Drew]

Now that Chrome extension support is out of beta, we're looking into
adding support for installing our Chrome extension into our Windows
installer. So, I've been looking at
http://code.google.com/chrome/extensions/trunk/external_extensions.html.

After reading it, my initial fear was that the extension's update_url
wouldn't be respected, and we'd have to update our extension manually
as the document describes instead of relying on Chrome's built-in
extension update functionality. However, I performed a quick test
using the "Update extensions now" button on chrome://extensions/, and
it appears that the update was performed successfully. It also
appears that the update "converted" the extension from being an
external extension to being a normal one (i.e. after updating,
removing the registry key no longer uninstalls the extension).

So, before relying on this functionality, I just wanted to make sure
it was all working as intended, and wouldn't be changed in a future
release. Specifically:

1) Is it intended for extensions initially installed as external to be
able to use update_url to update themselves and become normal
extensions?

2) After this process occurs, is there any harm in leaving the
registry key referencing the old .crx file and version in place?

Thanks.

Drew

[Finnur Thorarinsson]

Sorry Drew (for the late response).

I don't see a problem with external extensions using the update_url to update themselves.

However, the fact that the extension stops being an external extension once it is updated seems like a bug to me. You agree, Erik?

Anthony, I think the bug is caused by ExtensionsService::UpdateExtension calling CrxInstaller::Start with a hard-coded location of Extension::INTERNAL, whereas it could instead ask the extension for the location before the update and pass that in. Right?

So, my take on it is that you should not remove the reference to the old crx in the registry. If we fix this bug (mentioned above) the extension will be *uninstalled* after the key is removed.

Best regards,

Finnur

--
You received this message because you are subscribed to the Google Groups "Chromium-extensions" group.
To post to this group, send email to chromium-...@chromium.org.
To unsubscribe from this group, send email to chromium-extens...@chromium.org.
For more options, visit this group at http://groups.google.com/a/chromium.org/group/chromium-extensions/?hl=en.

[Drew]

That's good to hear... I tend to agree that it's a bit weird that an
external extension would be converted to an internal extension after
an update. However, I'm not sure what you mean by "it could instead

ask the extension for the location before the update and pass that

in". The location of the update is included in the response from the
update_url, right?

I guess to do all this properly while maintaining the external
extension, Chrome would really have to download the updated .crx, save
it to the same location pointed to by the external extension, and
update the version in the external_extensions.json file and/or
registry. I think this could pose a problem, as the location it tries
to save to could be a read-only network location, etc.

It would be nice to be able to update an external extension in this
manner while keeping it external, though, as it would make it much
easier to uninstall programmatically.

Drew

[Erik Kay]

Finnur - did you file a bug about the underlying issue?  It also feels like we need a unit test to cover this behavior.

On Fri, Feb 5, 2010 at 12:07 PM, Drew <zit...@gmail.com> wrote:

That's good to hear...  I tend to agree that it's a bit weird that an
external extension would be converted to an internal extension after
an update.  However, I'm not sure what you mean by "it could instead

ask the extension for the location before the update and pass that

in".  The location of the update is included in the response from the
update_url, right?

I think Finnur was talking about "location" in the sense of "is it external?", not the actual URL of the update.

 

I guess to do all this properly while maintaining the external
extension, Chrome would really have to download the updated .crx, save
it to the same location pointed to by the external extension, and
update the version in the external_extensions.json file and/or
registry.  I think this could pose a problem, as the location it tries
to save to could be a read-only network location, etc.

No.  In this model, these are simply two independent update mechanisms.  It doesn't matter if the version in the registry is old and out of date.  We don't support downgrades, so in that case the registry will just be ignored.  We don't need to keep the two systems in sync with each other.

 

It would be nice to be able to update an external extension in this
manner while keeping it external, though, as it would make it much
easier to uninstall programmatically.

Just curious, what's your use case?  The two use cases the system is supposed to support are:

(1) An extension that's tied to an application that is installed/updated/uninstalled independently of Chrome.  In that world, the extension may need to keep in sync with the version of the application, so it will only be updated when the extension updates, and will uninstall when the app is uninstalled.

(2) Extension "bundling" during some initial install.  For example, a computer maker may want to provide a set of default extensions for its users.  After the initial installation, the extension will update over the net, essentially acting like a normal extension.  There's no need for external uninstallation or updating.

It sounds like you're looking for something which is a bit of a mix of these cases, so I'm curious about the details.

thanks,

Erik

[Finnur Thorarinsson]

> Finnur - did you file a bug about the underlying issue?  It also feels like we need a unit test to cover this behavior.

http://code.google.com/p/chromium/issues/detail?id=34808

> I think Finnur was talking about "location" in the sense of "is it external?", not the actual URL of the update.

Correct. We keep track of this in a value called |location|, which I see now is easily mistaken for the update_url by those not intimately familiar with the Chrome Extensions codebase. :)

-F

[Drew]

Our use case is closer to #2 I guess, but isn't quite the same...
Basically, we have our extension on https://chrome.google.com/extensions,
and that's the only method for Mac and Linux users to install it.
However, we also allow Windows users to run an installer that installs
our Internet Explorer and Firefox extensions (and soon, our Chrome
extension) at the same time, among other things. Once the extension
is installed, regardless of how it's installed, we want updates to be
handled automatically by Chrome.

It seems at though this is already the case, and once the bug
discussed in this thread is fixed, our uninstaller will still be able
to uninstall the external extension we install, even if it's been
updated since the initial install.

Drew