54143 - ChatZilla only functional first time window comes up

Status: VERIFIED FIXED

(Other Applications :: ChatZilla, defect, P3)

Description

[Matthew Cline]

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.

Comment 1

[Vincent Schut]

hasn't this bug has already been mentioned as bug 51187 or at least in the
further commentes on this bug ?

Comment 2

[Matthew Cline]

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.

Comment 3

[eugfi]

I see the same behavior as reported by the original reporter:
Build ID 2000100108 Window98 Zip with Talkback

Comment 4

[David Krause]

*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.

Comment 5

[Jacob Steenhagen]

I've seen this on Win98 and Win2k... changing OS to all and adding self to CC.

Comment 6

[David Krause]

*** Bug 58169 has been marked as a duplicate of this bug. ***

Comment 7

[Stephen Ostermiller]

I confirm this bug.
2001010512 Linux 

Comment 8

[Samuel Sieb]

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.

Comment 9

[gary_Cope]

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 ?

Comment 10

[gary_Cope]

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);

Comment 11

[gary_Cope]

Attachment: attached a patch for static.js

Comment 12

[gary_Cope]

Attachment: attached a patch for handlers.js

Comment 13

[gary_Cope]

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.

Comment 14

[Robert Ginda]

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.

Comment 15

[Robert Ginda]

superbug checked in, mass marking all dependents fixed.

Comment 16

[Samuel Sieb]

verified on Linux CVS build

Comment 17

[timeless]

.