User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041105 Firefox/1.0RC2 (Debian package 0.99+1.0RC2-1) Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041105 Firefox/1.0RC2 (Debian package 0.99+1.0RC2-1) I have the webdevelopper extension installed, and the ~/.mozilla/firefox/default.*/extensions/{uid}/install.rdf says it requires firefox version 0.10+. On firefox 1.0RC1 and 1.0RC2, the webdevelopper toolbar still shows up and the extension is still enabled in the EM. If I disable it, it gets the "this extension is old" kinda message, though. Reproducible: Always Steps to Reproduce: 1. 2. 3.

Steps to simply reproduce: Start from a fresh install (I just re-did it with the firefox-installer-1.0rc2) Install webdevelopper 0.8 from http://update.mozilla.org/extensions/moreinfo.php?id=60&vid=645 Restart firefox as indicated. Then, the webdevelopper extension is enabled and will remain enabled whenever you start firefox. Then, go to the extensions manager and disable the extension. Restart firefox as indicated. The webdevelopper extension is now disabled, and can't be enabled again, because it's "Not compatible with Firefox 1.0".

Nutshell version of what's happening: the installer looks at install.rdf, sees too low a maxVersion, contacts update.mozilla.org, gets told a new higher maxVersion, and writes a temporary install.rdf with that. Then on restart, the temporary version gets it past the bouncer at the door, but Extensions.rdf is written with the old low value. First time you Update, either that specific extension in the EM or Firefox and extensions from prefs/options, the new higher maxVersion is actually written to Extensions.rdf, but until then, there's a window where you can disable and it will look like a too-old extension that can't be re-enabled until you select it and click update. Probably not a major problem, since the window is pretty small for people doing automatic updates, and unless you disable right after you install, when you're told it's too old you'll probably try to update it, but it would be nicer if the higher maxVersion from the temporary install.rdf could be written directly to Extensions.rdf during the install.

*** Bug 272298 has been marked as a duplicate of this bug. ***

Ben - this patch updates both the extensions.rdf and the extension's install.rdf if it exists and we have write access. During an install or upgrade that requires a restart it adds updatedMinVersion and updatedMaxVersion for the extension or theme to the extensions.rdf that is then read after the restart at the end of the installation process to update the extension's or theme's target application minVersion and maxVersion. If the install or upgrade doesn't require a restart (e.g. a theme) it just updates the extension's or theme's target application's minVersion and maxVersion. During _applyVersionUpdates it now also updates the extension's or theme's install.rdf.

BTW: With this patch it is possible to delete the extensions.rdf and retain the minVersion and maxVersion information since the extension's or theme's install.rdf is updated at the same time the extensions.rdf is updated.

lets get this early for b3

Updated patch so it will apply cleanly with or without the patch from bug 284515.

Modifying an extension's install.rdf doesn't seem like a good idea to me. That should be treated as readonly IMO. Is there no other way?

Now with the patch for bug 293419 landed it is not so critical to update the extension's install.rdf in that the extension will just show as disabled and incompatible if it's install.rdf is read again. The scenarios I can think of are when copying extensions from one profile to another or when ever the extensions.rdf is regenerated (e.g. trying to repair a profile by deleting the extensions.rdf). I would prefer to leave the install.rdf alone as well but I can see no way other than updating it or creating / managing another datasource alongside the install.rdf.

Why are we worried so much about extensions.rdf being deleted? That should only happen in very unusual cases, right?

I'm not so worried about it being regenerated now that the extension will install as disabled / incompatible with the landing of the patch for bug 293419. When upgrading from 1.0.x to 1.0+ the extensions.rdf is generated from scratch due to changes in the EM code since there is no code to upgrade an existing extensions.rdf. Though I would prefer not to modify the install.rdf I wasn't able to come up with any reasons not to except that it isn't "owned" by the app. The benefits of modifying the install.rdf have already been outlined except perhaps being able to delete the extensions.rdf if necessary with future versions of the EM code without disabling extensions as incompatible which is essentially where we are today. I really could go either way with this though I believe the user experience is better overall with modifying the install.rdf. If the install.rdf isn't modified I would also have to say that this patch is not nearly as important since within a week of install the compatibility info in the extensions.rdf will be updated.

That is, it will be updated within a week if update checking is enabled.

(In reply to comment #11) > When upgrading from 1.0.x to 1.0+ the extensions.rdf is generated from scratch > due to changes in the EM code since there is no code to upgrade an existing > extensions.rdf. Does this mean that if someone tries out Deer Park (an alpha, unstable, "don't rely on" version) they can't go back to 1.0.x using that profile? If this is true and intended it needs to be shouted from the rooftops. Nowhere on the download page or in the release notes does it say to create a new profile, nor are the instructions on how to do so (it's not so obvious in Firefox). Boy is *that* asking for trouble!

Dan: not exactly. It should be that once you upgrade, the list of extensions that you uninstall/disable on trunk will not match up with the extensions that you have installed/uninstalled/disabled with a 1.0.x build.

I don't think you should worry about extensions.rdf being deleted again. We shouldn't need to make such a drastic change to it again in the future.

Darin, I am less optimistic than you: the EM itself deletes extensions.rdf if it detects that things have gone wrong: http://lxr.mozilla.org/mozilla/source/toolkit/mozapps/extensions/src/nsExtensionManager.js.in#2269

bsmedberg: yeah, see comment #10 :-) it is only when bad things happen that we lose extensions.rdf. if we rely on updating install.rdf to make things work properly, then we will have at best a partial solution since updating install.rdf isn't an option for some globally installed extensions.

To fix the basic bug of not updating the minVersion and maxVersion during an install the data will need to be stored somewhere. Currently the patch uses the extensions.rdf to persist the data through the restart but it could use a separate file that would be located inside the extension's directory alongside the install.rdf. Since the install process for global extensions requires write access it will also be possible to do this for globally installed extensions. This additional file could be read if present to update the extensions.rdf with the extension's updated minVersion and maxVersion if the extensions.rdf ever went away, the user copied the extensions dir to a new profile, or if a time comes again when the extensions.rdf has to be built from scratch as is the case with the current EM code. The only case that I can think of where this won't work is with global extensions when the app is not launched by someone with write access to the app's extensions dir after an upgrade.

The install process for global extensions does not require write access. A superuser could unzip a XPI into the global location (or set a registry key under windows). The user of firefox may not have write access to those extensions. Requiring write access to those extension directories in order to make the system behave sanely is a bad idea.

Point taken though the file would not be required and it would fallback to using the install.rdf when it doesn't exist. Regretfully, there is no 100% solution where the updated info could always be provided though I believe it would approach 100% for non-corporate users since they tend to install extensions into a profile. I'll update the patch to only update the extensions.rdf later tonight. BTW: Aren't items installed via the registry managed independently and hence they wouldn't take part in this?

Ah, I didn't realize that this only applied to extensions managed by the Firefox. In that case, I think you don't have to worry about readonly global extensions. And, perhaps modifying install.rdf is OK :-)

I can better understand your concerns now. This won't update any items where an update check can't be performed like items installed by using a registry location. I can easily limit it to only updating the install.rdf for extensions installed into the profile directory or have it update extensions in the profile directory and the app directory if we have write access. I am leaning towards only extensions in the profile directory since it would provide a clear line of what is and what is not updated for documentation, troubleshooting, etc. while still resolving the majority of cases where this has come up before.

This patch will carry over the updated target app's minVersion and maxVersion when installing or upgrading an extension that is incompatible based on its install.rdf and has updated compatibility info that makes it compatible. It will also update the minVersion and maxVersion in the extension's install.rdf if it is installed into a profile's extensions directory during an install or upgrade and if updated compatibility info is found when it is compared to the compatibility info in the extensions.rdf during an update check.

Comment on attachment 185250 [details] [diff] [review] patch mozilla/toolkit/mozapps/extensions/src/nsExtensionManager.js.in 1.115

resolving fixed - thanks for the checkin timeless. I also verified when installing adblock from UMO that the updated minVersion and maxVersion are carried updated in the extensions.rdf and in the install.rdf if the extension is installed into the profile directory when the installation completes.