Darin Fisher Assignee
	Description • 19 years ago

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.

	Benjamin Smedberg
	Comment 1 • 19 years ago

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.

	Darin Fisher Assignee
	Comment 2 • 19 years ago

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?

	Darin Fisher Assignee
	Comment 3 • 19 years ago

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.

	Robert Strong (they/them - no direct email)
	Comment 4 • 19 years ago

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.

	Darin Fisher Assignee
	Comment 5 • 19 years ago

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?

	Robert Strong (they/them - no direct email)
	Comment 6 • 19 years ago

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.

	Benjamin Smedberg
	Comment 7 • 19 years ago

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.

	Darin Fisher Assignee
	Comment 8 • 19 years ago

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?

	Darin Fisher Assignee
	Comment 9 • 19 years ago

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.

	Darin Fisher Assignee
	Comment 10 • 19 years ago

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

This patch turns out to do the trick.

	Darin Fisher Assignee
	Comment 11 • 19 years ago

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

	Benjamin Smedberg
	Comment 12 • 19 years ago

Fixed for 1.1a2

	Darin Fisher Assignee
	Comment 13 • 19 years ago

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