Sunbird (default) theme not shown in new Add-ons Manager when using a profile from Sunbird 0.3a1 or Sunbird 0.3a1+ in Sunbird 0.3a2. Steps to reproduce: 1) Create a profile with Sunbird 0.3a1 or Sunbird 0.3a1+ nightly build 2) Open profile with Sunbird 0.3a2 --> 'Sunbird Update' dialog is shown but does nothing, must be canceled 3) Select Tools->Addons->Themes Actual Results: Window is empty, Sunbird (default) theme is not shown Expected Results: Sunbird (default) theme is shown --> The result of this is that you can't change back to default theme after installing and using a custom theme. Tested with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/2006042715 Mozilla Sunbird/0.3a2 hourly build. Blocking 0.3a2 release?

This should be fixed by bug 335667

I just verified that this will be fixed by bug 335667 and was caused by bug 329045

With bug 335667 checked in this shoould now be fixed. If someone could verify this I'd appreciate it. Thanks

(In reply to comment #3) > With bug 335667 checked in this shoould now be fixed. If someone could verify > this I'd appreciate it. Thanks I see no difference: If I open a profile created with Sunbird 0.3a1 the compatibility update check is running but nothing happens. If I cancel the check Sunbird starts and the Theme manager window is empty. The default theme is not displayed. Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/2006042907 Mozilla Sunbird/0.3a2

(In reply to comment #4) > If I open a profile created with Sunbird 0.3a1 the compatibility update check > is running but nothing happens. Not to hijack or morph this bug, but I've seen that behavior for a while. I went so far as to check and see if any network traffic was going on while it was "checking". Ethereal says no. Back to _THIS_ bug: I only see the default theme when starting 0.3a2 without an existing 0.3a1 profile.

Hmmm... the zip for 3.0a1 wasn't packaged with the default theme! The EM should be made to handle an upgrade where this has happened but that case hasn't been checked or handled previously which is probably why this bug is happening. I'm going to check out earlier versions to see if they were packaged with a default theme and how it handles it. I suspect this is also why the compatibility checker hangs on start as well... I'll take care of that as well.

bah, sunbird-0.3a2.en-US.win32.zip doesn't have the default theme packaged either! Can't very well show a theme when the install.rdf for it isn't provided.

It appears this has been broken since bug 286034 landed... Sunbird was never changed so the default theme would only be in the app's extensions directory. I'm going to compile Sunbird and verify this fixes this before requesting review.

Filed bug 335982 so that the profile default theme directories will be removed on upgrade. With 1.0.x we put the default theme in the profile directory. After bug 286034 landed the default theme was only stored in the app's extensions directory. If the default theme in the profile's extensions directory is not removed the previous theme's install.rdf is used for compatibility and can make it impossible to switch back to the default theme since it would be incompatible.

Package the default theme in the app's extensions directory (see bug 286034) Removes the app.extensions.version pref (see bug 304476) Changes Addons to Add-ons (typo from bug 335618)

BTW: The EM uses nsIXULAppInfo version which return 0.3a2 for Sunbird. It isn't necessary to implement the rest of bug 304476 though it does simplify setting the app version for release.

Comment on attachment 220295 [details] [diff] [review] patch Does this patch fix the theme not showing up or the never-ending update check? The first does not block sunbird0.3a2, the latter does.

(In reply to comment #12) > (From update of attachment 220295 [details] [diff] [review] [edit]) > Does this patch fix the theme not showing up or the never-ending update check? > The first does not block sunbird0.3a2, the latter does. The patch from bug 335982 will prevent the update check from occuring when there are only appManaged add-ons in the extensions datasource which will fix the never-ending compatibility check and it will also fix the default theme bug I commented about. For that patch to land this patch will need to land first. Also, for the patch in bug 335982 to fix the bug that causes the theme not to display an app version change will need to occur so anyone running 0.3a2 will not display the theme until their app version changes. There are also additional details in bug 335982.

I take that back about the theme not displaying... that patch will clean up the extra default theme in the profile directory and this patch will make it so it will display.

I made a build containing the patch attached here and the patch attached in Bug 335982: Going from Sunbird 0.2 to 0.3a2 build works fine. The default theme is displayed in Add-ons manager. Going from Sunbird 0.3a1 to 0.3a2 build is not OK. The default theme is still not displayed in Add-ons manager.

Comment on attachment 220295 [details] [diff] [review] patch This patch actaully is a workaround to the never-ending compatibility check: the check never ends because there are no extensions installed, so there is nothing to check. With this patch, there is a theme, and the check now finishes.

Comment on attachment 220295 [details] [diff] [review] patch Rob: will this patch work on the 1.8 branch? If so, please also checkin there.

(In reply to comment #15) > I made a build containing the patch attached here and the patch attached in Bug > 335982: > Going from Sunbird 0.2 to 0.3a2 build works fine. The default theme is > displayed in Add-ons manager. > Going from Sunbird 0.3a1 to 0.3a2 build is not OK. The default theme is still > not displayed in Add-ons manager. That may be due to nsIVersionComparator and Sunbird's 3.0a1 version actually being 0.3a1+. Also, going from 0.3a1 to the nightly just before the new add-ons mgr landed also doesn't display a theme. The patch in bug 335982 won't take affect in Sunbird until the version that is launched is different. (In reply to comment #16) > (From update of attachment 220295 [details] [diff] [review] [edit]) > This patch actaully is a workaround to the never-ending compatibility check: > the check never ends because there are no extensions installed, so there is > nothing to check. With this patch, there is a theme, and the check now > finishes. I was hoping it would but don't think it would under all circumstances. What ever the case, this brings Sunbird up to date in regards to several changes that should have been made long ago. I'll land on both trunk and branch today.

Checked in to trunk and MOZILLA_1_8_BRANCH

mvl, any plans to implement the remainder of bug 304476 for Sunbird? Also, do you think someone would be willing to take on verifying that Sunbird is in sync with Firefox in regards to the common areas of the code? I have no problem creating bugs / submitting patches as appropriate for Sunbird going forward in regards to the changes being made that I know about but I am a bit concerned that there are other changes that haven't been ported to Sunbird yet as bug 286034 and the rest of bug 304476 weren't which may cause other problems in the future.

From what i can tell, SUNBIRD_VERSION already is implemented, so I don't know what's left to port from bug 304476. As for the rest, one would hope that being a toolkit app means that there isn't much to port. The patch in bug 286034 is huge, so it's hard for me to tell what needs to be ported.

I noticed that SUNBIRD_VERSION isn't used in Sunbird's install.rdf... I suspect in other places as well. Searching lxr for FIREFOX_VERSION should find all the places it should be used in Sunbird. I believe the makefile changes from this bug are all of the changed needed to sync with bug 286034 but I'll make a note to check this when I have the time to do so.

(In reply to comment #22) > I noticed that SUNBIRD_VERSION isn't used in Sunbird's install.rdf... I suspect > in other places as well. Searching lxr for FIREFOX_VERSION should find all the > places it should be used in Sunbird. I implemented SUNBIRD_VERSION recently as a prerequisite for enabling the DOMi for Sunbird. I haven't gone through and made Makefiles use it since we are in code freeze.

(In reply to comment #22) > I noticed that SUNBIRD_VERSION isn't used in Sunbird's install.rdf... Patch created for install.rdf.in in bug 334417. (attachment 220347 [details] [diff] [review])

sadly, this still doesn't work. :( I tried with a profile created in sunbird0.3a1, then tried the last nightly. Still the never-ending compatiblilty check, and also the default theme isn't visible in the add-ons window. I added a dump("items: "+items.length); to the update function in nsIExtensionManager, at it says there are 0 items.

The patch in bug 335982 _seems_ to fix the never-ending compatibility check, but not the theme not showing up. (but i've said before that it seemed to be fixed, so i'm more careful now)

(In reply to comment #26) > The patch in bug 335982 _seems_ to fix the never-ending compatibility check, > but not the theme not showing up. (but i've said before that it seemed to be > fixed, so i'm more careful now) see comment #18

(In reply to comment #18) > That may be due to nsIVersionComparator and Sunbird's 3.0a1 version actually > being 0.3a1+. After running 0.3a1, compatibility.ini says LastVersion=0.3a1_2005110407/1.9a1_2005110407 Looks like 0.3a1 to me, not 0.3a1+ > The patch in bug 335982 won't take affect in Sunbird until the version that is > launched is different. Going from 0.3a1 to 0.3a2 is different. Or is it not different enough?

Robert, you are right about the theme not showing up in nightly builds before the change. I created test profiles with Sunbird 0.3a1 (20051104). If I open such a profile in Sunbird 0.3a1+ (20060217) everything is OK. (Update check is shown, connects to the internet, theme is shown afterwards) If I open such a profile in Sunbird 0.3a1+ (20060218) it fails. If I open such a profile in Sunbird 0.3a2 (20060501) it fails. (Update check takes forever, no internet connection, theme is not shown) Robert, can you check what check-in between 2006-02-17-06 and 2006-02-18-06 could be responsible and needs to be ported to Sunbird too?

(In reply to comment #29) > Robert, can you check what check-in between 2006-02-17-06 and 2006-02-18-06 > could be responsible and needs to be ported to Sunbird too? > Suspicious bugs include bug 324314 and bug 298497.

What changed there was the forced removal of the default theme in the profiles directory. As of bug 286034 we can't have a copy of the default theme in the profile directory due to it becoming disabled on upgrade (e.g. an app upgrade doesn't replace profile files like prefs.js, extensions, bookmarks, etc. all for good reasons) so we have to remove this copy on upgrade. Regretfully, Sunbird never had those changes added until now. With the patch from bug 335982 will prevent the never-ending check from happening but it doesn't handle the 0.3a1 to 0.3a2 upgrade appropriately in relation to the default theme appropriately which is what I am looking into atm. btw: you are correct regarding it not being 0.3a1+... I believe I was looking at a nightly when I noticed that

Just so you know, those changes are needed by Firefox and Thunderbird which did get the changes that Sunbird didn't so, backing that out really isn't an option.

It seems that the theme is shown after the second update: If I use a profile 0.3a1 --> 0.3a1+ (theme not shown) --> 0.3a2 (theme shown) I hacked a version of Sunbird 0.3a2 to identify as pref("general.useragent.extra.sunbird", "Mozilla Sunbird/0.3b1"); 0.3a1 --> 0.3a2 (theme not shown) --> 0.3b1 (theme shown) If I see it correct the theme is shown after the next update (0.3b1 in that case). If that is correct - and always working - we might just release note that fact and release Sunbird 0.3a2 as is.

I haven't had time to figure out what the cause is. The difference is that 0.3a1 didn't have the changes the patch in this bug provided and those changes were required to properly migrate from the old extensions datasource to the new one. I hope to have it figured out tonight and the patch will be against the EM and submitted in bug 335982.

This is caused by having both an install operation (e.g. app extensions dir) and an uninstall operation (e.g. profile extensions dir) for the same id (e.g. default theme id). Since this code path was only used when upgrading from the old extensions datasource the simplest solution is to remove the new extensions datasource on upgrade if it exists and the default theme exists in the profile directory. Any existing extensions / themes will automatically be re-installed and the only bad side affect should be that any extensions the user has explicitly disabled will be enabled.

I submitted a patch in bug 335982. I'm going to test some more before requesting review but so far this does the trick.

I tested 0.2 -> 0.3a2 and 0.2 -> 0.3a1 -> 0.3a2 successfully with the patch in bug 335982. Going from a nightly 0.3a2 without that patch to a nightly with that patch will not fix the problem since the code path is only called on upgrade. BTW: when upgrading from 0.2 to 0.3a1 I get the can't install message for the default theme. This has been broken a very long time and if you see any errors like that in the future please file a bug in Firefox -> Extension/Theme Manager or Toolkit -> Extension/Theme Manager if / when it gets moved to Toolkit.

The patch in bug 335982 has landed on trunk. resolving -> fixed

adding fixed1.8.1 since this landed on MOZILLA_1_8_BRANCH. I'll land the patch in bug 335982 hopefully later today on MOZILLA_1_8_BRANCH

verified with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060929 Sunbird/0.3