I believe that when creating the network tab in onStartConnect, the display() call throws and auto-perform fails to be sent as an indirect result. We've had at least two people in #chatzilla specifically have this problem on Firefox 3.6 and I have been unable to reproduce on Firefox 4.0 so far.

cz: Error routing event network.startconnect: + message (string) 'window.document.body is null' + fileName (string) 'chrome://chatzilla/content/static.js' + lineNumber (number) 2815 + stack (string) 853 chars + name (string) 'TypeError' * in onStartConnect TypeError: window.document.body is null cz: checkScroll([object XULElement])@chrome://chatzilla/content/static.js:2815 addHistory([object Object],[object HTMLTableRowElement],(void 0))@chrome://chatzilla/content/static.js:5146 __display("Connecting to irc://moznet/ (irc://irc.mozilla.org/)\u2026 [[Cancel][Cancel connecting to moznet][cancel]]","INFO",(void 0),(void 0))@chrome://chatzilla/content/static.js:4982 net_display("Connecting to irc://moznet/ (irc://irc.mozilla.org/)\u2026 [[Cancel][Cancel connecting to moznet][cancel]]","INFO")@chrome://chatzilla/content/static.js:4494 my_sconnect([object Object])@chrome://chatzilla/content/handlers.js:1998 ep_routeevent([object Object])@chrome://chatzilla/content/lib/js/events.js:278 ep_stepevents()@chrome://chatzilla/content/lib/js/events.js:346 mainStep()@chrome://chatzilla/content/static.js:1546 @chrome://chatzilla/content/static.js:1550

Might be a HTML5 parser regression?

Oh, how fun. Does the scrolling stuff work in other cases? The easy fix is to fall back to document.height, but I'd have expected things to be far more broken than just autoperform if window.document.body is missing.

It's fine once the output window is loaded, the problem is we're creating the tab, loading the output window document and trying to scroll down in one go (by displaying a message). It doesn't consitently happen either, which I believe confirms my theory that it's just while the document is not loaded enough. The fix should just be to check window.document.body exist in checkScroll.

(In reply to comment #0) > I believe that when creating the network tab in onStartConnect, the > display() call throws and auto-perform fails to be sent as an indirect > result. > > We've had at least two people in #chatzilla specifically have this problem > on Firefox 3.6 and I have been unable to reproduce on Firefox 4.0 so far. Not every time but often, on SeaMonkey 2.4a1 (corresponding to Firefox 7.0a1) when I start ChatZilla one of my three networks lacks the query and channel tabs from its auto-perform list. The network tab is present, and either /reconnect or "Chatzilla → Open auto-connect" opens the missing tabs. The problematic network is the one with the fewest tabs but it is the topmost nertwork in the list of auto-connect URLs in "ChatZilla → Preferences → Global → Startup". In case you want to try to reproduce the problem, I'm attaching the extensions.irc.* lines from my prefs.js; however I've left out the prefs showing my nicknames and I've obfuscated usernames (replaced by uuuuuuuu) and passwords (replaced by ppppppp).

Interesting, perhaps it isn't limited to <=3.6 then... but I've never had it happen on 4.0 during testing.

I'm starting ChatZilla as part of SeaMonkey startup, together with the browser (with a homepage of more than 140 tabs) and the 3-pane MailNews window. This may make race conditions all the more acute.

I accidentally hit this same problem joining a new channel on XR 2.0, so I think it probably is everywhere... just variable.

Occasionally (but less often) all tabs open, but in the first one to three tabs for the first server, which are query tabs (to services), the answer to the "implicit whois" (normally done when opening any query tab) is missing. The answer to the possible message (e.g. "You have 0 memos (0 new)" in answer to "/query MemoServ list") is there. Same bug or different bug? Or wait until this bug is FIXED and see if this problem disappears too?

http://hg.mozilla.org/chatzilla/rev/144f0c279a3b Tony, please check with the patched code (CZ nightly XPI won't be available until later today) and raise a new bug if it still happens.

(In reply to comment #11) > http://hg.mozilla.org/chatzilla/rev/144f0c279a3b > > Tony, please check with the patched code (CZ nightly XPI won't be available > until later today) and raise a new bug if it still happens. There's been one or more SeaMonkey linux-x86_64 builds since your comment above, I'll install the latest one then install the {59c81df5-4b7a-477b-912d-4e0fdf64e5f2}.xpi that comes with it and reload. Let's hope you don't hear for me on this subject anymore. ;-) This is an intermittent bug, however; we'll have to wait some time before declaring it has stopped happening.

Mozilla/5.0 (X11; Linux x86_64; rv:8.0a1) Gecko/20110713 Firefox/8.0a1 SeaMonkey/2.5a1 ID:20110713003104 I haven't had the problem (of comment #5) anymore, I think the bug can be declared VERIFIED. Problem of comment #10 has disappeared too. People, don't REOPEN this bug until you experience it soon, and in a ChatZilla built later than comment #11. You may also open a new bug with the 'regression' keyword. In all cases, please mention which versions of ChatZilla and of (Firefox, SeaMonkey or XULrunner) you used, and try to describe as clearly as possible what you did and what you saw, so that developers have a chance to reproduce the problem.

I'm not sure whether anyone affected will see this, but this patch also fixes my no-networks plugin, which is otherwise causing a similar problem on ChatZilla 0.9.87.