Closed Bug 272882 Opened 20 years ago Closed 19 years ago

Firefox doesn't exit properly with ChatZilla


(Other Applications :: ChatZilla, defect)

Not set


(Not tracked)



(Reporter: daneel, Assigned: rginda)


(Blocks 1 open bug)


(Whiteboard: [cz-patch][cz-0.9.69])


(1 file, 3 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

Sometimes FireFox doesn't exit correctly after using ChatZilla

Reproducible: Always
Steps to Reproduce:
1. Close Firefox and ChatZilla, make sure there are no running firefox processes.
2. Start ChatZilla directly, firefox.exe -chat
3. Start FireFox
4. Close ChatZilla
5. Close FireFox
Actual Results:  
The firefox.exe process doesn't terminate.

Expected Results:  

ChatZilla 0.9.66e
I've not tested with Firefox yet, but this sequence works fine in Mozilla. I
believe it is a command-line handling/startup bug, and not nessessarily specific
to ChatZilla.

Reporter, could you try doing -jsconsole in place of -chat, and see if the same
thing happens? Actually, I'm not sure you can open FF from the JavaScript

Also, when you say "start firefox", what did you do? Run "firefox.exe"? Or open
via a link in the ChatZilla window?
I am using a gnome menu item via it's launcher to launch chatzilla using the
command /usr/bin/firefox -chat (using the -chat switch). If I launch chatzilla
while a instance of Firefox is running I get that select a profile (profile
manager window) window, but if I launch it prior and launching Firefox after
launching chatzilla, the profile manager doesn't come up.
Just anote this is running Linux, Gentoo, Gnome 2.6.8, Firefox 1.0, and
Chatzilla 0.966e.
It doesn't happen until ChatZilla tries to connect to a server.
"start firefox" I mean run "firefox.exe".
So "-chat" doesn't cause it if it doesn't connect to a server, neither does
But "-chat irc://" does cause it.
This is not a ChatZilla bug, then, it is a Startup/Profile/whatever bug in
Firefox and Mozilla.

-chat does NOT take any parameter, so the command line "-chat irc://whatever/" is
interpreted by Mozilla/FF as -chat, plus a 'regular' URL. URLs open (or try to)
browser windows, or at least the contant handler registered for the protocol.
ChatZilla's irc: handler does NOTHING except launch the CZ window. Chances are
Moz/FF has opened a hidden window before asking the URL protocol handler.
Steps to reproduce (summary):
1. Start ChatZilla with an IRC server URL, e.g.
firefox.exe -chat irc://
2. Close Firefox
3. Firefox.exe will still be running.

firefox.exe -chat  doesn't cause it
firefox.exe irc://  doesn't cause it but opens an extra window.

James, you're probably right, and this isn't a ChatZilla problem.
Can you please change the bug report to better represent the bug?
(In reply to comment #6)
> firefox.exe -chat  doesn't cause it
> firefox.exe irc://  doesn't cause it but opens an extra window.

The second one there is very interesting... means it must be some interaction
between the two items. I suspect the fact -chat has a chromeUrlForTask
(chrome://chatzilla/content) associated with it might be related. The basic
effect of using both items is that two different places try to open a CZ window,
and presumably due to some bad interaction somewhere a window is left half-open
or something.
FYI This not only a .exe (Windows BUG) it's a Linux bug too
Good point, it's probably a startup/command0line bug in Moz, or at least a quirk.

--> All/All
OS: Windows 2000 → All
Hardware: PC → All
Blocks: 221245
Depends on: 253950
This simple patch prevents the theoretical hidden window from being created
when ChatZilla is invoked with the "-chat" parameter passed to Mozilla. It does
this by allowing chatzilla to accept irc[s] URLs to be passed as the value of
the "-chat" parameter. I have only tested this patch on SeaMonkey, so make sure
someone tests it on aviary to ensure that this bug is truly resolved. I also
welcome comments on the handling of "-chat" with no value; in this scenario, my
patch causes a message to display in the chatzilla client buffer stating that
an invalid URL was passed, but this message can be purged from my patch
depending on what the reviewers think.
Attachment #175450 - Flags: review?
This patch has the same effect as the first one submitted, but has more
efficient URL scheme testing based on review comments by Hannibal in
Attachment #175450 - Attachment is obsolete: true
Attachment #175463 - Flags: review?(justinarthur)
(In reply to comment #10)
>, bug relatingt o this issue.

Bug 253950 is somewhat related, but I don't think the resolution of this bug is
dependant on the resolution of bug 253950. If there were to be a dependency, I
think it would be in the opposite direction given that the behavior described in
this bug's comments could potentially contribute to the "confusion" described in
bug 253950.
I think we might want to change this bug's summary to reflect the fact that this
bug is not limited to the firefox platform.
Attachment #175463 - Flags: review?(justinarthur) → review?
This perfects the handling. No warning is given if a value doesn't follow the
"-chat" parameter. A warning is still shown if you pass it a non-IRC URL,
Attachment #175463 - Attachment is obsolete: true
Attachment #175518 - Flags: review?(jessiebarnes72)
Attachment #175518 - Flags: review?(jessiebarnes72) → review?(samuel)
Bug 253950 is completely unrelated.

JTA, this patch needs to be tested on:
  Mozilla 1.0
  Mozilla 1.4
  Mozilla 1.7
  Mozilla 1.8b2 (trunk)
  Firefox 1.0

(Firefox 1.0+ [trunk] has bigger issues)
No longer depends on: 253950
Hannibal provided me with this version of my patch using CVS instead of a local
Attachment #175518 - Attachment is obsolete: true
Attachment #181349 - Flags: superreview?
Attachment #181349 - Flags: review?
Attachment #175450 - Flags: review?
Attachment #175463 - Flags: review?
Attachment #175518 - Flags: review?(samuel)
Attachment #181349 - Flags: superreview?
Tested successfully on the following platforms:
- Firefox 1.0.3
- Mozilla 1.0 (thanks, Hannibal)
- Mozilla 1.8b1
- SeaMonkey from Trunk
Comment on attachment 181349 [details] [diff] [review]
Fixes Chatzilla's handling of -chat parameter values. (cvs diff version)

This looks ok, but I really don't have the time to test it myself. I know it
wont help FF 1.1/1.5, but that's a separate issue.

Also, I think some lines are longer than 80 chars, but I will re-format it
before check-in.

Attachment #181349 - Flags: review? → review+
Whiteboard: [cz-patch]
Checked in --> FIXED.

Sorry for the delay!
Closed: 19 years ago
Resolution: --- → FIXED
Whiteboard: [cz-patch] → [cz-patch][cz-0.9.69]
"C:\Program Files\Mozilla Firefox\firefox.exe" --chat direct command now doesnt work with firefox
(In reply to comment #21)
> "C:\Program Files\Mozilla Firefox\firefox.exe" --chat direct command now doesnt
> work with firefox

WFM, ChatZilla 0.9.73, Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20060508 Firefox/

On Windows, you need '-chat' (and/or maybe '/chat'), I'm not sure that '--chat' will actually work. It might very well not work.

You need to log in before you can comment on or make changes to this bug.