Closed Bug 54143 Opened 20 years ago Closed 19 years ago

ChatZilla only functional first time window comes up

Categories

(Other Applications :: ChatZilla, defect, P3)

x86
All
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: matt, Assigned: rginda)

References

Details

Attachments

(2 files)

Linux build 20000925, Linux 2.2.14 i686, RedHat 6.1

After starting up Mozilla, the first time that I bring up ChatZilla,
everything works fine.  However, if I close the ChatZilla window, and
then bring it up again, it ceases to function.  The window is there,
and I can type things into the text field, but pressing ENTER doesn't
do anything, not even clearing out the text field.  There isn't any
information in the box where the "Client" info normally goes, and there
aren't any tabs/lights/thingies up at top, when there's normally the
client tab up there.
hasn't this bug has already been mentioned as bug 51187 or at least in the
further commentes on this bug ?
Yes, it's been mentioned in that bug, but there seems to be two different
bugs: 1) the window doesn't even come up, and there are JavaScript errors;
2) The window does come up, without JavaScript errors, but it's non-responsive
and is missing the toolbar/tabs.

Since these are probably seperate bugs (although they both prevent you from
using Chatzilla), I think that there should be seperate bug reports; you
generally aren't supposed to report more than one bug per bug-report, unless
it's a tracking bug.
I see the same behavior as reported by the original reporter:
Build ID 2000100108 Window98 Zip with Talkback
*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
I've seen this on Win98 and Win2k... changing OS to all and adding self to CC.
OS: Linux → All
*** Bug 58169 has been marked as a duplicate of this bug. ***
I confirm this bug.
2001010512 Linux 
If you turn off XUL cache under the Debug preferences, you can close and restart
chatzilla.  However, be warned that this will slow down Mozilla.
I spent a bit of time looking at this. It appears that when chatzilla is
restarted client.output is getting initialised quicker than in initial startup.

Refer to: setOutputStyle (styleSheet) function
         ...
             client.output = oc.getElementById ("output");

When debugging client.output immediately after the assignment:
fresh chatzilla start: client.output = NULL
restart chatzilla    : client.output = [object HTMLDivElement]

The latter results in the setClientOutput function (which in turn calls
initStatic(), one of the main initialising functions for Client) not being
called in mainStep().

A fix for this is some way of ensuring that initStatic is called on restart:
in static.js: mainstep() function

@@ -380,2 +380,3
--- if (!client.output)
+++ if(!client.output)|| !client.statusBar) //ensure initStatic() called
+++                                         //on reopening chatzilla
        setClientOutput(frames[0].document);

and add the following to allow the document window to set up in time(I dont
understand whats happening with iframe/document here fully but this seems ok).
in handlers.js :onLoadFunction()
@@ -36,1 +36,1 @@
--- mainStep();
+++ setTimeout ("mainStep()", client.STEP_TIMEOUT);

This seemed to work as a pretty good fix and I couldnt see any bad consequences.
There may be a better way to ensure initStatic is called rather than a reference
to the existence of the client.statusBar.

I'd be happy to have this bug assigned to me. rginda what are your thoughts on
these patches ?

An errant right bracket found its way in there. Should be:-

@@ -380,2 +380,3 @@
--- if (!client.output)
+++ if(!client.output || !client.statusBar) //ensure initStatic() called
+++                                         //on reopening chatzilla
        setClientOutput(frames[0].document);
With regard to the setTimeout value of 50 millisecs added to handlers.js, I
found that even with a value of 1 millisec this caused the output window to
paint correctly (but not having setTimeout in at all caused it to paint 3/4 white).

I decided to set at a value of 50 millisecs as a conservative value in case less
powerful machines required more time before mainStep() could be called.

It seems a bit of a hack but it corrects the problem.
Thanks for debugging this, I think I see what's going on now.  The results
you're seeing when restarting chatzilla...
restart chatzilla    : client.output = [object HTMLDivElement]
is what's *supposed* to be going on, or at least that's what I thought until jst
set me straight in bug 29053.  The reason it fails the second time is that the
css comes from the cache (so the document load isn't blocked), which causes the
getElementById to *work*.  The codepath followed when |client.output =
oc.getElementById ("output");| actually works is broken.

The correct fix is to write an onload handler into the document in
setOutputStyle, and call setClientOutput when that event fires (as discussed in
bug 29053.)  We're going to need to move from the document.write()s used in
setOutputStyle to a static document eventually, in order to fix the "blank
window on theme switch" bug, so I'd suggest we hit them both with one fix.
Status: NEW → ASSIGNED
Depends on: 71468
superbug checked in, mass marking all dependents fixed.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
verified on Linux CVS build
.
Status: RESOLVED → VERIFIED
Product: Core → Other Applications
You need to log in before you can comment on or make changes to this bug.