Steps to reproduce: 1. Run some trunk compatible extensions with a 1.5.2 build 2. Then remove extensions.rdf, extensions.ini and extensions.cache 3. Run the latest trunk build 4. While starting up, the comptatibility checker comes up, but doesn't seem to do much except searching for something 5. When I close the checker, Firefox starts up but none of the extensions are listed.

What happens when you don't do step 2... removing files is not supported.

Then it works, it works also when you remove the files once more.

What happened is by removing those files the code thought your profile needed to be upgraded from a 1.0 profile. This is not a scenario the vast majority of users would perform on upgrade and removing files manually should never have to be done. resolved -> invalid

In a build of 1 April it worked.

I can believe that and quite a lot of the EM code was cleaned up in the patch from bug 329045. Upgrade code has a tendency to be a bit fragile and difficult to work with / maintain and deleting those files on upgrade is not a scenario I care to support. I'll take a look at this when time permits but if it works without deleting those files then it works as expected.

When I do have a chance to look at this it would be helpful to know if you have an Extensions.rdf in your extensions directory. Also, how does it behave if you remove it if it does exist?

One last question... why are you deleting the files? I know there have been reasons to delete them in the past due to bugs but the vast majority of them have been fixed and if you are deleting them due to a bug I'd really appreciate a bug report so I can fix it for 2.0. Thanks

Extensions.rdf is not present in the extensions folder. Only the extensions. Why I delete those files? I do that automatically before every startup of the test profile to make the profile clean on startup. It is all in one batchfile. It is just to exclude things that I might forget. The settings must be brought back to default etc. Just to be sure that it is a *new* profile with some basic prefs.

I'll take a look to see what if anything this might adversely affect for the non-batch file deletion of files case.

I reopen, for there *is* a problem. I don't know why I saw it different when I retested it (comment #2), but maybe I was a bit tired. When I skip now step 2, I see the problem. When you want to run a trunk build after 1.5.0.1, you first need to delete the 3 extension files that a mentioned, plus compatibility.ini.

Just to verify the steps: 1. Run some trunk compatible extensions with a 1.5.2 build 2. Run the latest trunk build 3. While starting up, the comptatibility checker comes up, but doesn't seem to do much except searching for something 4. When I close the checker, Firefox starts up but none of the extensions are listed. Actually, can you provide the steps again since the compatibility checker should not be displayed. Also, please do this without the use of the batch file so it is tested as the vast majority of users would experience it. Thanks.

Yes exactly. It fails also without installed extensions. There should be at least listed a talkback and a dom inspector, but nothing shows up.

"Actually, can you provide the steps again since the compatibility..." Can you provide the exact steps you are using? I especially would like to know if you are upgrading from a 1.5.x build to trunk. Are you changing install locations if / when you upgrade. Does the compatibility checker display? etc... Also, please let me know if you are NOT doing this with the batch file.

- I start a new profile with Firefox 1.5.0.2. No extensions. - I run the latest trunk build. - The checker comes up and I click Cancel - No extensions are listed whe Firefox opens. I expected Talkback and DOMI. - When I start a new profile with the trunk build, both are listed.

Benjamin, the change to the state property is what caused this bug. I removed the check for the property value and fixed the one place where the disabled property should still be used which is on upgrade when readin the old extensions datasource.

Fixed on trunk. This will need to be checked in on MOZILLA_1_8_BRANCH when bug 329045 is checked in

Ria, could you verify whether this is fixed or not? Thanks

Bah... this doesn't appear to have fixed this completely. reopening

(In reply to comment #17) > Yes, everything mentioned in this bug works perfectly now. Thanks.

Ria, you are right... this is fixed. Turns out there are a couple of other longstanding bugs that affected Sunbird. Bug 335753 bug 335982

Verbal a+ from bsmedberg... checked in on MOZILLA_1_8_BRANCH