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.
> - 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.
(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.
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.
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".
(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.
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.
Reproducible also on Linux when opening a new SM 2.0.14 profile with 2.1 RC1. The "modern" theme remains inaccessible... :-(
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.
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).
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.
Created attachment 533431 [details] [diff] [review] 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 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 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).
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.
(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 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
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.
Never mind, it's "classic/1.0" for the Firefox 5.0b2 default theme as well.
(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 <firstname.lastname@example.org> 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!
Filed bug 658283 for the general problem
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.
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.
I'm still waiting for RC2 build #2 to show up for testing, any ETA?
> I'm still waiting for RC2 build #2 to show up for testing, any ETA? should not make a difference.
(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.
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).