Closed Bug 54143 Opened 20 years ago Closed 19 years ago
Zilla only functional first time window comes up
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 ?
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.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.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
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
You need to log in before you can comment on or make changes to this bug.