Closed Bug 273423 Opened 18 years ago Closed 18 years ago

Can't install themes

Categories

(Core Graveyard :: Installer: XPInstall Engine, defect)

defect
Not set
blocker

Tracking

(Not tracked)

RESOLVED FIXED
mozilla1.8beta1

People

(Reporter: tracy, Assigned: benjamin)

References

Details

(Keywords: smoketest)

Attachments

(4 files)

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.
Severity: normal → critical
OS: Windows XP → All
Hardware: PC → All
(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.
Blocks: 275232
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).
Flags: blocking-aviary1.1?
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
Attached image jar=>xpi result
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"
Assignee: bugs → xpi-engine
Component: Extension/Theme Manager → Installer: XPInstall Engine
Product: Firefox → Core
QA Contact: bugs
Severity: critical → blocker
Flags: blocking1.8b?
Flags: blocking1.8a6?
Keywords: smoketest
Depends on: 272764
Assignee: xpi-engine → bsmedberg
Attachment #170473 - Flags: superreview?(bugs)
Attachment #170473 - Flags: review?(bugs)
So why is this part of toolkit while other parts of xpinstall localization are not?
Flags: blocking1.8a6? → blocking1.8a6+
(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.
Attachment #170473 - Flags: superreview?(bugs)
Attachment #170473 - Flags: superreview+
Attachment #170473 - Flags: review?(bugs)
Attachment #170473 - Flags: review+
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.
Attachment #170473 - Flags: approval1.8a6+
Fixed on trunk, with one change to jar.mn (there is an extra "xpinstall"
subdirectory which I missed).
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.8alpha6
removed smoketest keyword.  Adding a theme isn't a smoketest.
Keywords: 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
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
adding back the smoketest keyword as xpinstall is a smoketest for Seamonkey.
sorry about that, folks.
Keywords: smoketest
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.
Attachment #170974 - Flags: review+
(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?)?

Flags: blocking1.8b?
Flags: blocking1.8b+
Flags: blocking1.8a6+
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?
Blocks: 278590
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).
Status: REOPENED → RESOLVED
Closed: 18 years ago18 years ago
Resolution: --- → FIXED
Keywords: aviary-landing
Flags: blocking-aviary1.1?
Target Milestone: mozilla1.8alpha6 → mozilla1.8beta1
(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...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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.
Status: REOPENED → RESOLVED
Closed: 18 years ago18 years ago
Resolution: --- → FIXED
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. ***
No longer blocks: 278590
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.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.