267906 - Disabled extensions with a externally raised maxVersion claim to be incompatible

Status: RESOLVED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[Mike Hommey [:glandium]]

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.

Comment 1

[Mike Hommey [:glandium]]

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".

Comment 2

[Phil Ringnalda (:philor)]

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.

Comment 3

[Phil Ringnalda (:philor)]

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

Comment 4

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

Attachment: patch

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.

Comment 5

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

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.

Comment 6

[chris hofmann]

lets get this early for b3

Comment 7

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

Attachment: patch

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

Comment 8

[Darin Fisher]

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?

Comment 9

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

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.

Comment 10

[Darin Fisher]

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

Comment 11

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

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.

Comment 12

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

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

Comment 13

[Daniel Veditz [:dveditz]]

(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!

Comment 14

[Benjamin Smedberg]

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.

Comment 15

[Darin Fisher]

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.

Comment 16

[Benjamin Smedberg]

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

Comment 17

[Darin Fisher]

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.

Comment 18

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

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.

Comment 19

[Darin Fisher]

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.

Comment 20

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

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?

Comment 21

[Darin Fisher]

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 :-)

Comment 22

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

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.

Comment 23

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

Attachment: patch

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 24

[timeless]

Comment on attachment 185250 [details] [diff] [review]
patch

mozilla/toolkit/mozapps/extensions/src/nsExtensionManager.js.in 	1.115

Comment 25

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

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.