657957 - Migrating a SeaMonkey 2.0 profile to 2.1 reports modern and default themes as incompatible

Status: VERIFIED FIXED

(SeaMonkey :: Themes, defect)

Description

[rsx11m]

Steps to reproduce:
 - using a production profile that was initially migrated to 2.0 from 1.1.x
 - running 2.1 RC1 installer as released, custom install with some extension
   not chosen for installation (only picked DOMi, don't know if it matters)
 - installation proceeds, removed previous 2.0.14 installation as intended
 - going into Add-on Manager, reports "default" and "modern" themes are not
   compatible with 2.1; View > Apply Theme has SeaMonkey Modern item disabled
 - reinstalling from C:\Program Files (x86)\SeaMonkey\extensions resolves the
   issue, no more compatibility warning after update

I'm filing this for "Themes" though it may also be an issue with extensions.* not being correctly updated in the 2.0 profile to reflect the new version.

Comment 1

[rsx11m]

>  - reinstalling from C:\Program Files (x86)\SeaMonkey\extensions resolves the
>    issue, no more compatibility warning after update

That should read "after restart" of course. No such problems when installing without an existing profile. It also doesn't matter if the Windows account has administrator privileges or is a restricted account, and whether or not Software Installation is enabled in the preferences.

Comment 2

[Robert Kaiser]

(In reply to comment #0)
>  - reinstalling from C:\Program Files (x86)\SeaMonkey\extensions resolves the
>    issue, no more compatibility warning after update

That puts those into the profile, where they always override the application's copies and never get updates, which esp. together is dangerous, at least for a normal users.
I'd think that a simple restart should be sufficient as well, though I wonder why this happens at all.

Comment 3

[rsx11m]

I had tried a restart a couple of times for both accounts without any success. Moving the themes into the profile folder in this way isn't a desired fix, I'd certainly agree with that and wasn't quite thinking through my "solution" here.

Comment 4

[rsx11m]

Upon further testing, I've removed the in-profile default and modern themes using the Add-ons Manager, and after restart I see the installation versions of both themes listed in the Appearance tab, both marked as "incompatible".

Comment 5

[Robert Kaiser]

(In reply to comment #4)
> Upon further testing, I've removed the in-profile default and modern themes
> using the Add-ons Manager, and after restart I see the installation versions
> of both themes listed in the Appearance tab, both marked as "incompatible".

Could you look into their install.rdf? Something definitely smells fishy there.

Callek, if this is a general issue, it could very well end up being a problem for release.

Comment 6

[rsx11m]

Looks correct for both default and modern themes in the extensions folder:

      <em:minVersion>2.1</em:minVersion>
      <em:maxVersion>2.1</em:maxVersion>

Also, as they install as "regular" XPIs into the profile, they seem to be fine.

As a sanity check, I've just created a completely new profile with 2.0.14, then opened it with 2.1, seeing the same issue; thus, it's not my specific profile.

Comment 7

[rsx11m]

Reproducible also on Linux when opening a new SM 2.0.14 profile with 2.1 RC1.
The "modern" theme remains inaccessible...  :-(

Comment 8

[rsx11m]

More after reading http://forums.mozillazine.org/viewtopic.php?f=3&t=2201501

 - New 2.0.14 profile opened with 20110511 2.1pre nightly -> incompatible;
 - new 2.0.14 profile opened with 20110512 2.1.1pre nightly -> incompatible;
 - update 20110512 2.1.1pre nightly to 20110518 2.1.1pre -> compatible;
 - new 2.0.14 profile opened with 20110518 2.1.1pre nightly -> incompatible.

Thus, I'd expect the issue to be "fixed" with an upcoming 2.1 -> 2.1.1 update, though that would imply that users won't have a modern theme until then.

Comment 9

[Jens Hatlak (:InvisibleSmiley)]

(In reply to comment #8)
> Thus, I'd expect the issue to be "fixed" with an upcoming 2.1 -> 2.1.1
> update, though that would imply that users won't have a modern theme until
> then.

This is also what I found, but that implies that all users use 2.1 and not install 2.1.1 directly (which I might do if I was a regular user).


Confirming (Linux, SM 2.1.1pre nightly) with reduced STR:
1. Create a profile using SM 2.0.x
2. Run SM 2.1.x with the above profile.

That is to say this I can reproduce this without using the installer by using first SM 2.0.x and the SM 2.1.x (installed into different directories, but both as my user), simply extracted from the archives.

Actually we're lucky that the Default theme is used even though it's marked incompatible. BTW that's also the case if you migrate a SM 2.0.x profile that had a theme active that is both third-party and incompatible with SM 2.1.x (like Orbit 3+1).

Some notes; hopefully I don't add to the confusion:

1. Modern is listed under [ThemeDirs] in extensions.ini in the affected profile before the upgrade, but not anymore after the upgrade.

2. The issue seemed to fix itself when I renamed extensions.sqlite in the affected profile after the upgrade (the file is not present before the upgrade, i.e. it's newly created by SM 2.1).

3. If you set extensions.lastAppVersion to say 2.2, the themes are listed as compatible again. SM will set extensions.lastAppVersion to the correct value itself after a restart.

4. A similar issue is with extensions that are installed by default, like Venkman (JavaScript Debugger). If you migrate a fresh 2.0 profile, there is no problem. But if you let SM 2.0 upgrade Venkman to the latest version from AMO, then it'll be incompatible after the upgrade. [The difference here is that Venkman is available on AMO and the version there is indeed incompatible with SM 2.1 (and FF 4) because there is no Venkman release anywhere containing the fixes have that had been committed to the repositories some months ago.] Other than the themes, you can remove Venkman, but then you cannot get it back easily (but that's not specific to the upgrade problem and will be fixed automatically when a new Venkman release has been uploaded to AMO, whenever that will be).

Comment 10

[Robert Kaiser]

Mossop, any idea what could be happening there?
Apparently extensions.sqlite has some wrong data after those updates (note that SeaMonkey 2.0 is based on Mozilla 1.9.1 and SM 2.1 is based on Mozilla 2.0).

Comment 11

[Dave Townsend [:mossop]]

Looks like your classic and modern themes don't change version across app updates like Firefox's does. This means we think the theme hasn't changed and so we use the compatibility information we had from extensions.rdf instead of that in the install.rdf. Probably shouldn't do that for stuff in the app dir so there's a bug in there we can fix fairly easily for future versions. For now the easiest way around this is just to bump the versions of your themes.

Comment 12

[Jens Hatlak (:InvisibleSmiley)]

Attachment: patch [Checkin: comment 17]

What Mossop said (kept the internal version since it is used elsewhere and breaks things as such).

Feel free to request more feedback; it's pretty clear that we need some testing coverage here in addition to a simple code review. Also some tryserver build or similar might be useful to let the reporter verify the solution.

[Not taking for the moment in case this approach is wrong or not accepted.]

Comment 13

[Justin Wood (:Callek)]

Comment on attachment 533431 [details] [diff] [review]
patch [Checkin: comment 17]

Land this.

I'll also want this landed on 2.0 incase there is a chemspill we have to address.

I'll be respinning 2.1 for this, so please request approval(s) for any bugs that are good ridealong candidates.

New ETA for release, tuesday. Will spin tomorrow night.

Comment 14

[Robert Kaiser]

Comment on attachment 533431 [details] [diff] [review]
patch [Checkin: comment 17]

I wonder somewhat if we might want to do the same with debugQA - but if so, in a different bug as debugQA doesn't affect the 2.1 release (not shipped with a release).

Comment 15

[rsx11m]

See http://forums.mozillazine.org/viewtopic.php?f=6&t=2197535 for debugQA, different case though as it installs now in the profile on purpose.

Comment 16

[Jens Hatlak (:InvisibleSmiley)]

(In reply to comment #13)
> Land this.

Will do (c-c and c-2.0) in a minute.

> I'll also want this landed on 2.0 incase there is a chemspill we have to
> address.

OK, I'll leave this open then; I have no build environment ready for 1.9.1 currently.

> I'll be respinning 2.1 for this, so please request approval(s) for any bugs
> that are good ridealong candidates.

Bug 657215 please (just nominated).

Comment 17

[Jens Hatlak (:InvisibleSmiley)]

Comment on attachment 533431 [details] [diff] [review]
patch [Checkin: comment 17]

http://hg.mozilla.org/comm-central/rev/7a3897444476
http://hg.mozilla.org/releases/comm-2.0/rev/ac9c579e9694

Comment 18

[rsx11m]

I've patched the XPI files in RC1 extensions/ manually and it resolved the 2.0->2.1 migration problem for me, great! I'm only wondering about those lines:

     <em:internalName>classic/1.0</em:internalName>
     <em:internalName>modern/1.0</em:internalName>

Shouldn't they be changed to @SEAMONKEY_VERSION@ as well to match <em:version>?
The Add-ons Manager doesn't seem to care and shows me 2.1 for either theme.

Comment 19

[rsx11m]

Never mind, it's "classic/1.0" for the Firefox 5.0b2 default theme as well.

Comment 20

[Jens Hatlak (:InvisibleSmiley)]

(In reply to comment #18)
> I've patched the XPI files in RC1 extensions/ manually and it resolved the
> 2.0->2.1 migration problem for me, great! I'm only wondering about those
> lines:
> 
>      <em:internalName>classic/1.0</em:internalName>
>      <em:internalName>modern/1.0</em:internalName>
> 
> Shouldn't they be changed to @SEAMONKEY_VERSION@ as well to match
> <em:version>?

No, see comment 12. I tried.

> Philip Chee <[e-mail]> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>            Keywords|checkin-needed              |
>              Status|ASSIGNED                    |RESOLVED
>          Resolution|                            |FIXED
>    Target Milestone|---                         |seamonkey2.1final
>   Status Whiteboard|[c-n: comm-1.9.1]           |

Grr. Philip, please pay more attention!

Comment 21

[Dave Townsend [:mossop]]

Filed bug 658283 for the general problem

Comment 22

[Jens Hatlak (:InvisibleSmiley)]

Comment on attachment 533431 [details] [diff] [review]
patch [Checkin: comment 17]

Sorry KaiRo, totally missed your f+ on checkin. Next time I'll try not to rush it so much.

Comment 23

[Jens Hatlak (:InvisibleSmiley)]

http://hg.mozilla.org/releases/comm-2.0/rev/bef0efa21d60

Comment 24

[rsx11m]

Verified with 2.1 RC2 build #1 (en-US) on both Windows 7 and Linux x86_64; no problems when migrating a 2.0.14 profile any more, themes have 2.1 versions.

Comment 25

[rsx11m]

I'm still waiting for RC2 build #2 to show up for testing, any ETA?

Comment 26

[Philip Chee]

> I'm still waiting for RC2 build #2 to show up for testing, any ETA?
should not make a difference.

Comment 27

[Justin Wood (:Callek)]

(In reply to comment #26)
> > I'm still waiting for RC2 build #2 to show up for testing, any ETA?
> should not make a difference.

With regards to this bug, correct should not make a difference.

Also it looks like in my deep investigation that RC2 Build 2 should be equal to RC2 Build 1 for everything except localized windows installer builds. But the way the tooling is, it is MUCH better to issue a whole new set of builds for the issue than try and redo what I need.

Comment 28

[Justin Wood (:Callek)]

Actually, thank you rsx11m for mentioning "WFM in SeaMonkey 2.0.x" and causing me to think about this again, yea its not really "right" for SeaMonkey 2.0.x, but given that it was the first SeaMonkey with that toolkit stuff, we don't need this there. (If there was an older SeaMonkey, or for some reason we bumped to 2.1.foo there it would be needed, but thats not the case).