299021 - Support updating optionally installed components

Status: RESOLVED FIXED

(Toolkit :: Application Update, defect)

Description

[Darin Fisher]

Support updating optionally installed components

Things like DOM inspector and talkback may or may not be installed.  We want to
be able to build a single udpate archive that can be used to update the user's
copy of Firefox, and we want to make sure that we don't install DOM inspector in
the process of updating them to the next release of Firefox.  Likewise, partial
updating of DOM inspector code would fail if DOM inspector were not present.

My solution to this problem involves adding the following new rules to
update.manifest:

  add-if "test-file" "target-file"
  patch-if "test-file" "patch-file" "target-file"

Basically, these rules would only be applied if "test-file" exists.  The test
file can be either a normal file or a directory.

Comment 1

[Benjamin Smedberg]

I'm not sure what I think about updating DOMI using this system: we end up with
a situation where DOMI is being updated by both the extension update and app
update systems.

Talkback and anything else not installed into <appdir>/extensions, sure.

Comment 2

[Darin Fisher]

Right now DOMI is shipped with an install.rdf that lacks an updateURL, so it is
not being updated by the extension manager.  Since DOMI is shipped with the
initial download, it makes sense that an updated version would be available with
every firefox release, and so updating it with firefox seems natural to me. 
Alternatively, we could decouple it completely, but then we have the issue that
users who never explicitly install an extension will be confronted with
extension update UI when firefox silently updates itself to a new version of
firefox.  Given that use case, I would much rather have firefox update all of
its components, including the extensions that ship with it.

Ben, do you have any thoughts on this?

Comment 3

[Darin Fisher]

Attachment: v1 patch

I haven't fully tested this patch yet, but this is what I think the
implementation of add-if and patch-if will look like.

Comment 4

[Robert Strong (they/them - no direct email)]

FWIW - any extension that does not have an updateURL is checked for updates
against UMO. I also agree that it should be updated when the app is updated. It
may make sense to add a new flag to the install.rdf for identifying extensions
and the default theme that the extension update system shouldn't try to update.

Comment 5

[Darin Fisher]

Ben told me that the extension manager was not supposed to update extensions
lacking an updateURL.  He said that it was a bug that the menu item in the
extension manager showed that the item could be updated.  Perhaps no updateURL
implying UMO is used to simplify the task of using UMO as the update system for
most extensions?  What happens if an empty string is specified for the updateURL?

Comment 6

[Robert Strong (they/them - no direct email)]

Ben must have forgotten... here is where it is checked for a value
http://lxr.mozilla.org/seamonkey/source/toolkit/mozapps/extensions/src/nsExtensionManager.js.in#4860

and if there is no value for updateURL it uses this
http://lxr.mozilla.org/seamonkey/source/toolkit/locales/en-US/chrome/mozapps/extensions/extensions.properties#23

I am sure it is to simplify maintaining extensions but unless I am badly
mistaken it responds the same for extensions that are already up to date as it
does for extensions that aren't hosted there which makes displaying errors more
problematic... and there is the issue of not being able to set the state of
cmd_update by the absence of the updateURL  :/

If updateURL="" it will check UMO for an update. Keep in mind that it will only
try to update it if there is info on UMO based on the extension's id.

Comment 7

[Benjamin Smedberg]

We definitely want to keep the system where no updateURL uses the default UMO
URL. This is a good design. The updateURL specified in install.rdf is really
just an override mechanism.

Comment 8

[Darin Fisher]

I agree that having no updateURL should imply the default UMO one.  Should we
change the meaning of an empty updateURL?  Is it easy for the code to
distinguish those two cases?

Comment 9

[Darin Fisher]

Attachment: patch for tools/update-packaging

This patch assumes that the optional components will actually be items in the
extensions folder.  This ends up including the install.rdf file for the default
theme, but that's ok as it just means that we'll have an add-if instruction
where an add instruction would have been sufficient.

I also updated make_incremental_update.sh for good measure even though that
isn't being used yet.

Comment 10

[Darin Fisher]

Comment on attachment 187581 [details] [diff] [review]
v1 patch

This patch turns out to do the trick.

Comment 11

[Darin Fisher]

It'd be good to get this in for Alpha 2 if possible.

Comment 12

[Benjamin Smedberg]

Fixed for 1.1a2

Comment 13

[Darin Fisher]

"patch for tools/update-packaging" is now in on the trunk