Nightly build 200091508 on WinNT4. Chatzilla is not in the tasks menu. Mozilla -chat didn't work either.
This still seems to be the case in 2000091920 on Win2K.
This is a dup of something. Someone with time please go find it.
Also found bug 17767 which may or may not be related (I'm not sure).
Could this be caused by some of the recent rdf/jar changes/problems? I'm going to check tomorrow to see if this is still a problem. I just built on linux and chatzilla is in the menu but doesn't seem to load. It seems to have started a "ghost" window that I can't see. Will explore this further tommorrow also. I don't think bug 17767 is related. That bug is about reoranizing the layout of the Task menu.
Build 2000092205 on WinNT: Chatzilla is not in the Tasks menu. ./mozilla -console -chat displays the splash screen and then hangs. Bug 51187 may be related. According to that bug chatzilla is in the Tasks menu on Win98 but doesn't work.
Chatzilla used to be in the tasks menu... that bug is from older builds. That bug can't be fixed until this one is.
This is installed-chrome.txt issue. A easy workaround adds the following line in installed-chrome.txt content,install,url,jar:resource:/chrome/chatzilla.jar!/content/chatzilla/ locale,install,url,jar:resource:/chrome/chatzilla.jar!/locale/en-US/chatzilla/ skin,install,url,jar:resource:/chrome/chatzilla.jar!/skin/modern/chatzilla/ But chatzilla don't run...
Makoto Kato's suggestion worked great for putting Chatzilla back in the tasks menu. Based on that information, it seems to get it back into the builds, all that has to be done is a 30 second changed to installed-chrome.txt that gets packaged with the ZIP files. This seems like a very low impact change.
rginda, If you have no time, please assign to me. I have fix codes.
installed-chrome.txt gets generated during the build process. Checking in changes to it would ba a bad thing. Makoto, if your fix is for the build process, and not just changes to installed-chrome.txt, please attach it to this bug andI'll review it.
This patch fixed chrome install problem. And theme package out of modern.jar like chatzilla.jar, cannot select. When there is no theme, it is selected classic theme at force. So I change theme name to "classic". rginda, please review this patch. I have check in permission.
I'm sorry, but I don't understand your description of why you needed to change modern to classic. In fact, I don't even know why chatzilla needs to know about skin names, but that's probably something I should take up with hyatt. Other than that, r=rginda; you'll probably need an a= from brendan or waterson.
The default value of Mozilla theme selectors (chrome) is "classic". If there is no chatzilla's theme for your selected theme, it uses "classic" chatzilla's theme. Many themes won't include chatzilla's theme. So it should set default skin. So, if it does not move chatzilla's theme to mozilla/theme directory, theme name should be "classic".
Chatzilla should be able to pick whichever theme it chooses to skin itself with, even if it provides its own completely new theme. The only way that problems could arise is if chatzilla's XUL or CSS from one theme tries to load CSS from another package, and those CSS files do not exist. (Theme authors are allowed to create their own file structure). Other than that, the patch looks ok. a=ben.
Makefile.* only checkd in. skin issue branch to bug 51187.
Why the F*** does chatzilla have to care *anything* about skins? All I want is a widget set. I don't want to have to create a new skin for each XUL app, and I don't want my XUL app to depend on any pre-installed skin. That would be silly. What happens in this case if the user deletes the classic skin? The whole idea that a XUL app needs to mention a skin at all makes me ill.
I ran into the same problem with xmlterm! On starting, Mozilla would look for the xmlterm CSS files in skin/classic, and since they were actually in skin/modern, it would hang. If I changed the theme pref in mozilla to modern, then it would work. Since the skin for xmlterm is just a simple window at the moment, and I want a user to be able to run xmlterm regardless what mozilla's choice of theme is, I ended up moving my CSS files to the chrome content directories. This is probably a Bad Thing. I'll move them elsewhere when I find out what the Right Thing is. cc'ing myself to the bug
This bug has cropped up recently in the Linux nightlies (since the Linux nightlies started using the install program.) Changed O/S to All
*MASS SPAM* Changing QA contact on all open or unverified ChatZilla bugs to me, David Krause, as I am now the QA contact for this component.
QA Contact: rginda → David
David, are you still seeing this? If not, I think this bug should be resolved fixed. If so, the OS should be change to linux as it seems to be working fine on win32....
Jake, thanks for your help. Marking WORKSFORME. I no longer see this problem on Windows or Linux.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME
vrfy windows, and i think solaris, but currently solaris is out of memory so i'm coring mozilla :)
Status: RESOLVED → VERIFIED
Wrong David... :)... I meant David Orme. Also, shouldn't this be RESOLVED FIXED as it was a problem and then it was solved? I thought WORKSFORME was for bugs that could never be confirmed...
Jake, WORKSFORME is the closest resolution for this bug and is often used for bugs that used to be confirmed and now they can not be reproduced. FIXED means "A fix for this bug is checked into the tree and tested." Since there was no checkin for this bug and the problem went away, I marked it WORKSFORME. The cause of this bug was most likely bug 54595.
You need to log in before you can comment on or make changes to this bug.