Seen on Windows Firefox build 2004-12-06-08-trunk -Select Tools | Themes -In the themes manager, select Get More Themes -At the web page, click on a theme ( I tried qute and noia) -Click Install Now or -Right click Download Theme and download the theme .jar file to your desktop -Drag and drop the jar to the Themes manager. tested results: nothing happens epected results: the theme istaller window appears and allows the theme to be installed note: extensions can be installed as expected.

I can confirm that dragging a jar file to the left pane of the Themes window results in nothing happening. Today's build fixed the extension installation regression but left this issue outstanding. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20041206 Firefox/1.0+, last modified 2004-12-06-1123.

Extensions install just fine, however, if you intended to say that the installation of Themes was fixed today (not by dragging but by clicking on Install) then no, it's definitely not fixed.

The only way to use Themes at this point is to reuse an old profile from Firefox 1.0 for them to transfer over. Off Bug Report Topic: Extensions have actually been installing from the Zip builds (not sure about the Installer builds since they've had various issues for a while) since about 12-02-04 if I remember correctly. Themes have never been able to install by drag and drop yet. /Ieremiou

Re: comment #3. Drag and drop has always worked on aviary branch builds. Please don't add comments to bugs with misinformation without checking first. It does not help in resolving problems.

(In reply to comment #4) > Re: comment #3. Drag and drop has always worked on aviary branch builds. > Please don't add comments to bugs with misinformation without checking first. > It does not help in resolving problems. I never Said AVIARY and for one this is a TRUNK discussion so AVAIRY is not being discussed. Try again.. Plus the Avairy 1.0 has been out since November and I sourced the 12-02-04 builds (which aren't avairy builds since Avairy is DEAD) as a reference so reread. If i don't say Avairy I mean the trunk. When I meant never I meant since using the Trunk builds after the aviary-landing since this is a topic about the aviary-landing and not avaries or anything else but the trunk. So you should know that we aren't discussing the avairy. since it's dead.

Re; comment #5. Check the keywords. This is an Aviary-landing bug. Try again yourself. If you mean it never worked on the trunk say that. I agree it never worked on the trunk. It worked on Aviary.

(In reply to comment #6) > Re; comment #5. Check the keywords. This is an Aviary-landing bug. Try again > yourself. If you mean it never worked on the trunk say that. I agree it never > worked on the trunk. It worked on Aviary. I just insaleed a load of themes, using drag and drop of .jar files and .xpi installation... WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8a6) Gecko/20041208 Firefox/1.0+ Am I missing something??

re comment #7: Strange. It still does not work in the en-US version: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20041209 Firefox/1.0+

I did more testing, and that is indeed the case. Works for me with en-GB version fails with en-US version.

Looks like the only way toget thems installed, is to not completely remove a good profile from a 1.0 Branch build that has themes installed. Just my personal observation from installing Trunks the past week.

Not sure if this helps but the theme install buttons are javascript, so I opened the Tools > Javascript Console and found lots of errors. I am having this trouble to using the latest nightly... -HTH Art Wildman Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20041220 Firefox/1.0+ (Session Saver & Custom Tabbed Extensions) ------------ Error: Selector expected. Ruleset ignored due to bad selector. Source File: http://www.squarefree.com/burningedge/styles-site.css Line: 105 Error: Unknown property 'a'. Declaration dropped. Source File: https://addons.update.mozilla.org/core/update.css Line: 64 Error: Selector expected. Ruleset ignored due to bad selector. Source File: https://addons.update.mozilla.org/core/update.css Line: 191 Error: Expected ':' but found 'itemdescription'. Declaration dropped. Source File: https://addons.update.mozilla.org/themes/moreinfo.php?application=firefox&id=72&vid=1292 Line: 0

(In reply to comment #11) > Not sure if this helps but the theme install buttons are javascript, so I opened > the Tools > Javascript Console and found lots of errors. Those are all just CSS errors on the sites in question.

I'll add that this problem is still present in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a6) Gecko/20041224 Firefox/1.0+ Extensions install fine but Theme installs trigger no action.

Maybe missing chrome://global/locale/xpinstall/xpinstall.properties causes this. There are references both 'communicator/xpinstall/' and 'global/xpinstall/', and trunk builds only contain 'communicator/xpinstall/'. http://lxr.mozilla.org/mozilla/search?string=xpinstall.properties

I can't install themes in usual ways, but if we rename the .jar file into .xpi, the themes can be installed by drag and drop (Although the extension window appears) Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20041227 Firefox/1.0+

Renaming to xpi WFM as well. Win32 build, 2004-12-11.

So now we have a workaround. A workaround which may point to the error(s) in the code to recognize jar files as theme files, or some such. Can we get this fixed already?

this is also a problem in thunderbird trunk builds (eg, 2005010304-trunk on Mac OS X 10.3.7).

Now that bug 272764 has been fixed, this has shown up as an issue in seamonkey as well. See https://bugzilla.mozilla.org/show_bug.cgi?id=272764#c88

jar=>xpi method is not well for all cases. Some JAR's "do not contain install script". So install any working XPI theme and replace it's JAR file in profile/chrome with the one failed to install. ie http://www.spuler.us/smoke/install.html Mozilla 20050105

Copy this attachment to the following location on your hard drive: /locale/en-US/global/xpinstall/spinstall.properties and add it to: mozilla/chrome/en-US.jar The result will be that jar files can be installed like before. /HJ

This bug is introduced, in Mozilla, by the patch for bug 242529. We should change the following line to make it work, without the previous work around/hack: http://lxr.mozilla.org/mozilla/source/xpinstall/src/nsInstall.h#76 -#define XPINSTALL_BUNDLE_URL "chrome://global/locale/xpinstall/xpinstall.properties" +#define XPINSTALL_BUNDLE_URL "chrome://communicator/locale/xpinstall/xpinstall.properties"

So why is this part of toolkit while other parts of xpinstall localization are not?

(In reply to comment #22) > This bug is introduced, in Mozilla, by the patch for bug 242529. We should > change the following line to make it work, without the previous work around/hack: > > http://lxr.mozilla.org/mozilla/source/xpinstall/src/nsInstall.h#76 > -#define XPINSTALL_BUNDLE_URL > "chrome://global/locale/xpinstall/xpinstall.properties" > +#define XPINSTALL_BUNDLE_URL > "chrome://communicator/locale/xpinstall/xpinstall.properties" Thanks for the suggestion. I applied this to my source tree and rebuilt Firefox. I can now install themes in the regular way.

so this officially makes seamonkey depend on toolkit. is this the first such instance?

(In reply to comment #26) > so this officially makes seamonkey depend on toolkit. is this the first such > instance? -> bug 272764 ??

The toolkit GNOME shell stuff is built by seamonkey already.

Comment on attachment 170473 [details] [diff] [review] Make canonical location uniform OK, r+sr=ben@mozilla.org to clear the blocker.

Comment on attachment 170473 [details] [diff] [review] Make canonical location uniform a=asa (on behalf of drivers) for checkin to 1.8a6. If this isn't the right thing to do, let's revisit after a6. We need to get it out the door and in sufficiently good shape to get some gecko and stability testing. This fix will help us get the downloads we're after. Thanks guys.

Fixed on trunk, with one change to jar.mn (there is an extra "xpinstall" subdirectory which I missed).

removed smoketest keyword. Adding a theme isn't a smoketest.

this works fine with 2005011108-trunk ffox builds on Windows (tested by Tracy) and Mac. however, this doesn't work (yet) on linux; but that's using 2005011107-trunk bits, which might not have picked up the fix in time.

I think this Checkin has brocken the XP-Installer on 1.8a-Trunk again. Using Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a6) Gecko/20050111 Mnenhy/0.7.0.10002 {}Build ID: 2005011111} I can't install Themes, neither other *.xpi-Packages (Have tried de-AT.xpi for Nightly-Builds). XP-Install worked fine for me with 2005011019 last tested. First reported in de.comm.software.mozilla.nb from Jochen Amsink, <34ir0pF4chkv3U1@individual.net> thanks to him. Think Mozilla 1.8a6-Release can't be shipped with brocken XP-Install. Please verify this another time and reopen this one, asking for new Blocking 1.8a6 Flag.

yep, xpinstall is broken with the latest tinderbox build 2005-01-11-11-trunk it was working fine with the build from 2005-01-11-05-trunk

adding back the smoketest keyword as xpinstall is a smoketest for Seamonkey. sorry about that, folks.

So why did the installer get broken by this bug's patch? Just wondering, not up on xpinstall enough, want the "diagnosis for dummies" story. /be

Basically, this is aviary-merge gone haywire, there are two canonical locations for this xpinstall.properties file, and there are multiple pieces of code referencing both locations. After this landed I found two more. It also turns out that the aviary code merge included some really broken stuff like http://lxr.mozilla.org/mozilla/source/xpfe/components/extensions/src/Makefile.in#47 EXTRA_COMPONENTS must be before rules.mk in order to do anything. So http://lxr.mozilla.org/seamonkey/source/xpinstall/src/nsSoftwareUpdate.cpp#367 fails. In addition, that version of nsExtensionManager.js has basic broken QI impls (it doesn't QI to nsISupports). I backed out the seamonkey portions of this patch so that we can get 1.8a6 out the door, per Asa. Then we can fix things even more properly.

This got tested/reviewed by biesi; I'll land when I reland the seamonkey portions of this patch after the alpha is done.

(In reply to comment #39) > Created an attachment (id=170974) [edit] > The other two references. > > This got tested/reviewed by biesi; I'll land when I reland the seamonkey > portions of this patch after the alpha is done. So this was broken (again) because you didn't change nsInstall.h, but moved xpinstall.properties, right?

HJ: no, it's because nsInstall.h had already been changed, and I moved the file to match, but the references in xpinstall/res/content were never changed.

(In reply to comment #41) > HJ: no, it's because nsInstall.h had already been changed, and I moved the file > to match, but the references in xpinstall/res/content were never changed. Oh ok, thanks for the info.

Ok, it's fixed now. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050113 Firefox/1.0+

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050116 Firefox/1.0+ Confirming that this bug WFM. I installed theme both by clicking on their links and letting the theme manager pick it up and by downloading the jar and dragging it into the theme manager. Both worked fine. Can we get this marked as fixed?

People, please please read bugs before commenting. See comment 39, in particular, and note that that checkin hasn't happened yet. In general, it's a good idea to look at the CVS logs for the files in the patches to see whether the patches landed...

(In reply to comment #39) > This got tested/reviewed by biesi; I'll land when I reland the seamonkey > portions of this patch after the alpha is done. Does the table at the top of this bug page mean that this is waiting (since the 11th) on a 2nd superreview? Or, was it tied up because of the alpha work (since done?)?

Is there a known timetable when this bug will be fixed? It's still a problem with the latest 1.8b build, which is why it's now blocking 1.8b, or am I misreading that?

I'm sorry to keep bringing this up, but what's happening with this bug? On 01/11/05, the POC implied (I think), that he knew what needed to be done but was tied up with the alpha. The box near the top of this bug page indicates it either went into or out of review on 01/11/05. After that, nothing. Is it still in review? Awaiting superreview (for over three weeks)? Tied up because of other work? Fallen through the cracks?

Fixed on trunk (again).

(In reply to comment #49) > Fixed on trunk (again). I installed the latest trunk earlier today (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050210) and I am not able to install themes from jar files or some XPI files. I have been able to install some themes from XPI files, but only a select few. Based on this, I would disagree that this bug has been resolved.

I rebuilt Mozilla specifically to check this bug the evening of Feb 8 and I can't install themes either. I audited my source to verify that the bsmedberg's patch was applied: xpistatus.xul institems.xul and jar.mn were patched, but mozilla/xpinstall/res/locale/en-US/xpinstall.properties is still missing from my source and bonsai. I do have the file in toolkit, but why is mozilla using the toolkit? What was the patch supposed to do to xpinstall.properties? Remove it or restore it? What does it mean when you patch a missing file? Anyway, it used to be when I tried to install themes nothing at all happens. Now, it downloads the file, tries to install it and gives me "Unexpected error -201".

Yes, that is what has been happening to me - I apologize for not including the error message. I get the "Unexpected error -201" after going through the process of downloading/installing the theme. I ended up reinstalling 1.8a5 to install the theme. Now that it is my profile, I am okay with any future builds until this gets fixed. I have to wonder, though, as I had one theme (orbit-1_8a-MiK.xpi) install with no problems with the build I mentioned in Comment #50. Oh well...

Good catch! Yeah, I can install xpi themes, but not jar themes. The workaround in comment #20 does apply. I can install an xpi theme and replace the jar file with the file that won't install. So, it's definitely not fixed, but it's good enough for me.

Reopening per comments. ccing biesi, since it's his r= on the patch...

I believe I once traced that to an nsIExtensionManager dependency in xpinstall...

Have there been some related javascript changes? I tried installing pinball_2005-02-01_1.8a6.xpi, but it failed with errors 202 (local) and 204 (global). I looked at the install.js from orbit-1_8a-MiK.xpi and based on that code changed line 29 in pinball's install.js. -addFile(sChromeNode, "placeholder", fChrome, sChromeName); +addFile(sChromeNode, sChromeName, fChrome, ""); And it installed. Could there be some similar mixup in whatever Mozilla is doing to install themes?

The extensionmanager problems, if there are any, should be solved by the patch in bug 278534 (not for 1.8b1).

re-resolving. Please reopen if this isn't the right thing.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050221 Firefox/1.0+ (daihard: P4/SSE2) Theme installation appears to have broken again, and attachment 174975 [details] doesn't appear to have been reviewed or checked in. Can anyone confirm?

Theme installation was resolved by marking it as "resolved fixed" not by actually fixing it, so it would be incorrect to suggest that it is broken _again_. It would be more correct to say it is broken _yet_. But that might not be correct either as I've seen a recent check-in that looks like it might fix it. Wouldn't it be cool to have a software bug tracking tool that would keep track of bugs as they are reported and fixed?

I can install Themes, but I noticed a little issue: Firefox makes a copy from installed Themes at Folder Chrome in profile. Bug or Feature???

*** Bug 278590 has been marked as a duplicate of this bug. ***

Well, I installed the latest trunk dated today, 3/14/2005, 1.8b2 after receiving an e-mail stating that this problem had been fixed. I am happy to report that it has - no more "-201..." errors. But, a new problem has shown up. I am unable to have any other theme than Classic be visible in the applications. If I select "Modern", shut down and restart - it is still in "Classic" mode. I am not running "Quick Launch". So, I can install themes, but am unable to use them afterwards. Just thought I would let someone know. I apologize if this is the wrong area to post this or if it had already been brought up. I am fairly new to bugzilla.

Okay, I did some poking around in my profile and found that the "overlayinfo" folder isn't being created in the "Chrome" folder of my profile. I also did a test. I told 1.8b2 to use the Mostly Crystal theme I just downloaded. Of course, stayed as the "Classic" theme. I then deleted 1.8b2 and installed 1.8b (released version). I then started Mozilla and changed my theme. The new theme changes appeared as expected. I then deleted 1.8b and reinstalled 1.8b2 and when it started up, it was using the Mostly Crystal theme. Here is the strange part. When I installed 1.8b and changed my theme, the "overlayinfo" folder was there. When I installed 1.8b2 and started it up - the folder was gone. Thought this would be of some assistance. Sorry for not doing more testing before my last post.

Confirming Jeff Lee. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050314 Not am I not only unable to switch from classic to modern, the work-around of encapsulating a .jar in an .xpi with an appropriate install.js file, also fails. The respective theme is there and visible but entirely unusable. I'd request that someone with appropriate permissions please re-open this bug that would appear to be neither resolved or fixed.

(In reply to comment #63) (In reply to comment #64) (In reply to comment #65) > Confirming Jeff Lee. > I'd request that someone with appropriate permissions please re-open this bug > that would appear to be neither resolved or fixed. There is already a bug filed for this recent regression: Bug 284521.