Chatzilla not in Tasks menu in nightly build.



Other Applications
18 years ago
14 years ago


(Reporter: David Krause, Assigned: Robert Ginda)


Windows NT

Firefox Tracking Flags

(Not tracked)



(1 attachment)



18 years ago
Nightly build 200091508 on WinNT4.

Chatzilla is not in the tasks menu.
Mozilla -chat didn't work either.

Comment 1

18 years ago
This still seems to be the case in 2000091920 on Win2K.

Comment 2

18 years ago
This is a dup of something. Someone with time please go find it.


18 years ago
Depends on: 37542

Comment 3

18 years ago
Also found bug 17767 which may or may not be related (I'm not sure).


18 years ago
No longer depends on: 37542

Comment 4

18 years ago
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.

Comment 5

18 years ago
I've been using 
javascript:openDialog("chrome://chatzilla/content/chatzilla.xul", "", 
"chrome,resizable,dialog=no"); instead of menus (and similarly for other apps), 
if this works then the problem is in between.

Comment 6

18 years ago
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.

Comment 7

18 years ago
Chatzilla used to be in the tasks menu... that bug is from older builds.  That
bug can't be fixed until this one is.


18 years ago
Blocks: 51187

Comment 8

18 years ago
This is installed-chrome.txt issue.
A easy workaround adds the following line in installed-chrome.txt


But chatzilla don't run...

Comment 9

18 years ago
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.

Comment 11

18 years ago
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.

Comment 14

18 years ago
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 
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.

Comment 18

18 years ago
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.

Comment 19

18 years ago
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

Comment 20

18 years ago
This bug has cropped up recently in the Linux nightlies (since the Linux
nightlies started using the install program.)

Changed O/S to All

Comment 21

18 years ago

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

Comment 22

18 years ago
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....

Comment 23

18 years ago
Jake, thanks for your help.  Marking WORKSFORME.  I no longer see this problem
on Windows or Linux.
Last Resolved: 18 years ago
Keywords: verifyme
Resolution: --- → WORKSFORME

Comment 24

18 years ago
vrfy windows, and i think solaris, but currently solaris is out of memory so 
i'm coring mozilla :)
Keywords: verifyme

Comment 25

18 years ago
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...

Comment 26

18 years ago
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.
Product: Core → Other Applications
You need to log in before you can comment on or make changes to this bug.