424107 - Extension updates installed from app mismatches window are lost

Status: RESOLVED FIXED

(Toolkit :: Add-ons Manager, defect, P2)

Description

[Godmar Back]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12
Build Identifier: http://download.mozilla.org/?product=firefox-3.0b4&os=osx&lang=en-US

In brief: we need a transition path 2.0 -> FX3 that ensure uninterrupted service. When a user updates and checks for a compatible extension, it must be offered and installed.

What happens in my test is that on the 2->3 transition, it'll say that a compatible extension is available, it'll appear to install it, but on restart it's still disabled. [ Manually checking for an update, installing it a second time, then restarting reenables it. ]

To us, this is a show stopper because it likely means the loss of many users if this isn't fixed for the 2->3 update.


Note this is with a "just-installed" extension so the an earlier update.rdf check have seen the new, compatible extension [ and in any event, earlier checks will be done by FF2, not FF3. ]

Reproducible: Always

Steps to Reproduce:
1. In FF2.0, install http://libx.org/editions/5C/FB/5CFB7B98.1/libx-5CFB7B98.xpi (in a chroot, ideally.  Note this extension will connect to sites such as ezproxy.lib.vt.edu or oclc.org).

2. Start FF3.0b4

3. Select "Check for Updates", it'll say there is an update.  Download and install the update, which will succeed.

4. Restart FF.  Note the extension is still disabled. Bug.

5. Go to Tools->add-ons.  Check for updates again.  Install. Restart.  Note the extension works now (which gives me the confidence that my update setup is correct.)

Actual Results:  
User thinks there is no compatible extension available when in fact there is.

Expected Results:  
The extension should be upgraded to a compatible version when user updates from FF2.0 to FF3.0.

As a matter of fact, you ought to be checking first for the availability of a compatible update *before* reporting to the user that the extension will be disabled [and asking the user if they wish to check.]

Tested on MacOSX 2.0.0.12 -> FX3.0.
Other than that, it was a fresh profile with nothing else installed.

Note that the FX3 version of my extension uses secure hashes to comply with secure update requirement. See

http://libx.org/editions/5C/FB/5CFB7B98/update.rdf

Comment 1

[Godmar Back]

I apologize for the hasty typing. I meant:

Note this happens with a "just-installed" extension so an earlier update.rdf
check won't have seen the new, compatible extension [ and in any event, earlier
checks will be done by FF2, not FF3. FF2 does not know about the necessity of secure updates for extensions.]

This comment is in reference to a bug I found in the database where someone pointed out that it's an edge case when Firefox updates shortly after an extension was installed [so that, in other words, the old Firefox version hadn't had time to check if an update was available during the normal extension update check.] 

Comment 2

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

I know this problem somehow similar from Fx1.5->2 and Fx2->3. Extensions which weren't compatible on migration time never got automatic reenabled.

Comment 3

[Dave Townsend [:mossop]]

We probably should block on this as it makes user migration to firefox 2 more irritating than it needs to be especially given that the UI we bombard them with is broken and so pointless.

Comment 4

[Mike Beltzner [:beltzner, not reading bugmail]]

Yeah, this blocks.

(In reply to comment #0)
> As a matter of fact, you ought to be checking first for the availability of a
> compatible update *before* reporting to the user that the extension will be
> disabled [and asking the user if they wish to check.]

There's a bug on that somewhere already, and while I agree that it's a better UE, it won't block this release (just like it didn't block Fx2 ... yeah, I cry a lot, too)

Comment 5

[Dave Townsend [:mossop]]

In an ironic twist this bug is caused by the code that migrates updateKey's in from already installed extensions in the newly running Firefox 3 app.

On startup in checkForMismatches for any add-ons that appear insecure we re-read their install.rdf to check if there was an updateKey there that previous versions of Firefox 2 would not have added to the main datasource.

Then we offer to find updates and install them by extracting them into the appropriate directories and reading their install.rdf to add them to the datasource.

Unfortunately the rdf service is caching the ds loaded the first time and just giving it to us on the second read so although the new version has been extracted into the directory we end up adding the manifest from the old version back into the datasource.

This patch makes us bypass the rdf caching by loading the text from the file manually and running it through an rdf parser. There are no longer any places where we actually write data to an install manifest and attempt to load it later.

There is likely to be a small performance penalty for this when actually upgrading items in place on startup, we load the same rdf a couple of times in succession so caching would be saving us a little bit, but this is a rare case and working around it would require a lot of work I believe.

There is a simple unit test that just checks the in-place detection and install of add-ons. If the rdf cache were in effect it would install the same metadata each time. This also removes the hack I had to put in place to clear out the rdf cache from the testing code. In looking at this I discovered that the EM wasn't quite getting called properly and so have copied the calling code verbatim from nsAppRunner.cpp now to ensure it is correct. This introduced one test failure that is really a test problem, it was assuming there were no add-ons installed where in fact the default theme is there but previously wasn't detected on startup.

Comment 6

[Dave Townsend [:mossop]]

Attachment: patch rev 1

Comment 7

[Dave Townsend [:mossop]]

Checking in toolkit/mozapps/extensions/src/nsExtensionManager.js.in;
/cvsroot/mozilla/toolkit/mozapps/extensions/src/nsExtensionManager.js.in,v  <--  nsExtensionManager.js.in
new revision: 1.282; previous revision: 1.281
done
Checking in toolkit/mozapps/extensions/test/unit/head_extensionmanager.js;
/cvsroot/mozilla/toolkit/mozapps/extensions/test/unit/head_extensionmanager.js,v  <--  head_extensionmanager.js
new revision: 1.4; previous revision: 1.3
done
Checking in toolkit/mozapps/extensions/test/unit/test_bug394717.js;
/cvsroot/mozilla/toolkit/mozapps/extensions/test/unit/test_bug394717.js,v  <--  test_bug394717.js
new revision: 1.2; previous revision: 1.1
done
RCS file: /cvsroot/mozilla/toolkit/mozapps/extensions/test/unit/test_bug424107.js,v
done
Checking in toolkit/mozapps/extensions/test/unit/test_bug424107.js;
/cvsroot/mozilla/toolkit/mozapps/extensions/test/unit/test_bug424107.js,v  <--  test_bug424107.js
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/toolkit/mozapps/extensions/test/unit/data/test_bug424107_1.rdf,v
done
Checking in toolkit/mozapps/extensions/test/unit/data/test_bug424107_1.rdf;
/cvsroot/mozilla/toolkit/mozapps/extensions/test/unit/data/test_bug424107_1.rdf,v  <--  test_bug424107_1.rdf
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/toolkit/mozapps/extensions/test/unit/data/test_bug424107_2.rdf,v
done
Checking in toolkit/mozapps/extensions/test/unit/data/test_bug424107_2.rdf;
/cvsroot/mozilla/toolkit/mozapps/extensions/test/unit/data/test_bug424107_2.rdf,v  <--  test_bug424107_2.rdf
initial revision: 1.1
done

Comment 10

[Godmar Back]

I'm confused which beta this bug is fixed in.  Bug 427745 reports against FX3 beta5, but beta5 was released after this bug had been marked FIXED.

Thanks.

Comment 11

[Dave Townsend [:mossop]]

This was fixed after the beta 5 freeze so will be in the rc. If it was fixed for b5 the target milestone would say so.

Comment 12

[Godmar Back]

The "target milestone" says "Firefox 3" - I'm slow - could you explain what that means?  Will there or won't there be any chance for us to verify the bug fix before FX3 comes out?

Keep in mind that bug reporters like myself are not (and really should not) be familiar with the details of release process.

Thanks.

Comment 13

[Dave Townsend [:mossop]]

As I said, it will be in the RC. You are of course always welcome to download the latest nightly and test the behaviour there.

Comment 14

[Umesh]

Could you please point to one the nightly builds in which the fix for this issue is available? We cannot afford to loose all the user base build for our extensions on FF2 on the click of their upgrade to FF3.

Thanks

Comment 15

[Godmar Back]

It would also be nice if Dave clarified what he means by "RC," keeping in mind that Mozilla developers should not assume that bug reporters are familiar with Mozilla's internal development cycle and terminology.  I assume that "RC" means release candidate, but how many will there be?  And why does it say in the "target milestone" Firefox 3 when it fact the target is the (first, I assume?) release candidate? Or this is implied, but if so, why was a beta released without the fix?

It would be wonderful the emails I receive from bugzilla clearly stated: this bug is fixed now, please download the build at such and such a URL to confirm the fix, rather than expecting us to decipher what's a beta, what's a release candidate, and what's targeted for what.

Thanks.