242095 - Topic, Mode and Users are set to <unknown> when using an irc bouncer

Status: RESOLVED FIXED

(Other Applications Graveyard :: ChatZilla, defect)

Description

[Oliver Eikemeier]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040421
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040421

Topic, Mode and Users show <unknown> when connecting to an irc bouncer (muh or
miau) that is already connected to an irc server.

Funny thing is, the topic in the title bar is correct, and when you try to
change the topic by clicking in the header, the correct topic is displayed.

Reproducible: Sometimes
Steps to Reproduce:
1. Set up an irc bouncer (muh or miau)
2. connect the bouncer to one or two channels on your favourite server
3. connect to the irc bouncer. disconnect. reconnect.

Actual Results:  
Topic <unknown> is shown in the header.

Expected Results:  
Display the correct topic.

/topic doesn't help. Also it looks like the client is swallowing join/exit messages.

I can sent a tcpdump and/or screenshots if requested.

Btw, Chatzilla asks for the bouncer password *twice*.

Comment 1

[Oliver Eikemeier]

the client shows join messages, as well as mode changes,
but exit messages don't show up.

Comment 2

[James Ross]

There should be no reason for quit messages to be missing, unless the bouncer is
sending a broken format for them (unlikely).

I would suggest you try the following to debug what's going on with the topics:

1. Start ChatZilla, but don't connect to anything yet.
2. On the client tab (use /client to show it if it's not there) enter the following:
  dd = function _dd(m) { client.display(m, "DD"); }
3. Also enter this onto the client tab:
  /pref debugMode t
4. Connect to your bouncer and join a channel.
5. Copy the log from the client view with all the lines starting "Level ", and
attach it to this bug, or post it online somewhere we can look.

A tcpdump might be useful, but the above will include any parsing that
ChatZilla's doing any is more likely to show the problem (it's more verbose,
too). Also, what versions have you tried?

Comment 3

[James Ross]

Actually, if you can run Mozilla from a console (*nix) or with -console (Win)
and not bother with Step 2, that would probably be better. The log will then be
in the console (apparently Mozilla throws some errors occasionally when using
step 2).

Comment 4

[Oliver Eikemeier]

(In reply to comment #2)

Ok tried the first method first. Some relevant lines may be:

[DD]	Level 1: 'rawdata', server[172.16.0.172].onRawData
data : ':irc.inet.tele.dk 376 eik :End of /MOTD command.'
	[DD]	Level 2: 'parseddata', server[172.16.0.172].onParsedData
	[DD]	Level 3: '376', network[172.16.0.172].on376
	[DD]	Level 1: 'rawdata', server[172.16.0.172].onRawData
data : ':irc.inet.tele.dk 306 eik :You have been marked as being away'
	[DD]	Level 2: 'parseddata', server[172.16.0.172].onParsedData
	[DD]	Level 3: '306', network[172.16.0.172].onUnknown
	[DD]	Level 1: 'rawdata', server[172.16.0.172].onRawData
data : ':eik!miau JOIN :#bsdports'
	[DD]	Level 2: 'parseddata', server[172.16.0.172].onParsedData
	[DD]	Level 3: 'join', server[172.16.0.172].onJoin
	[DD]	Error routing event server.join: + message (string) 'e.user has no properties'
+ fileName (string) 'chrome://chatzilla/content/lib/js/irc.js'
+ lineNumber (number) 1737
+ stack (string) 312 chars
+ name (string) 'TypeError'
*
in onJoin
TypeError: e.user has no properties
	[DD]	serv_join([object Object])@chrome://chatzilla/content/lib/js/irc.js:1737
ep_routeevent([object Object])@chrome://chatzilla/content/lib/js/events.js:202
ep_stepevents()@chrome://chatzilla/content/lib/js/events.js:263
mainStep()@chrome://chatzilla/content/static.js:1171
@chrome://chatzilla/content/static.js:1172
	[DD]	Level 1: 'rawdata', server[172.16.0.172].onRawData
data : ':irc.inet.tele.dk 332 eik #bsdports :Please review / test:
<http://lists.freebsd.org/pipermail/freebsd-current/2004-May/026663.html>'
	[DD]	Level 2: 'parseddata', server[172.16.0.172].onParsedData
	[DD]	Level 3: '332', server[172.16.0.172].on332
	[DD]	Level 4: '332', channel[#bsdports].on332
	[DD]	Level 1: 'rawdata', server[172.16.0.172].onRawData
data : 'irc.inet.tele.dk 333 eik #bsdports eik 1083416012'
	[DD]	Level 2: 'parseddata', server[172.16.0.172].onParsedData
	[DD]	Level 3: 'irc.inet.tele.dk', network[172.16.0.172].onUnknown
	[DD]	Level 1: 'rawdata', server[172.16.0.172].onRawData
data : ':eik!miau JOIN :#bsdcode'
	[DD]	Level 2: 'parseddata', server[172.16.0.172].onParsedData
	[DD]	Level 3: 'join', server[172.16.0.172].onJoin
	[DD]	Error routing event server.join: + message (string) 'e.user has no properties'
+ fileName (string) 'chrome://chatzilla/content/lib/js/irc.js'
+ lineNumber (number) 1737
+ stack (string) 312 chars
+ name (string) 'TypeError'
*
in onJoin
TypeError: e.user has no properties
	[DD]	serv_join([object Object])@chrome://chatzilla/content/lib/js/irc.js:1737
ep_routeevent([object Object])@chrome://chatzilla/content/lib/js/events.js:202
ep_stepevents()@chrome://chatzilla/content/lib/js/events.js:263
mainStep()@chrome://chatzilla/content/static.js:1171
@chrome://chatzilla/content/static.js:1172
	[DD]	Level 1: 'rawdata', server[172.16.0.172].onRawData
data : ':irc.inet.tele.dk 332 eik #bsdcode :Teenager raped by man with
inflatable sheep: http://news.scotsman.com/index.cfm?id=489572004&20040430182254'
	[DD]	Level 2: 'parseddata', server[172.16.0.172].onParsedData
	[DD]	Level 3: '332', server[172.16.0.172].on332
	[DD]	Level 4: '332', channel[#bsdcode].on332

The topic is in the title bas of the window. I have
[TOPIC]	Topic for #bsdports is “Please review / test:
<http://lists.freebsd.org/pipermail/freebsd-current/2004-May/026663.html>”
in the channel tab, but <unknown> in the Header. It *is* there when I try to
change the topic by clicking in the header, though. The same for #bascode.

This is from ChatZilla 0.9.63a. I tried Mozilla 1.6, the version included with
1.7b und decided to upgrade to the latest version in the hope to fix the bug.

For joining and leaving and I have:

[DD]	Level 1: 'data-available', server[172.16.0.172].onDataAvailable
	[DD]	Level 1: 'rawdata', server[172.16.0.172].onRawData
data : ':eik_!~[e-mail] JOIN :#bsdports'
	[DD]	Level 2: 'parseddata', server[172.16.0.172].onParsedData
	[DD]	Level 3: 'join', server[172.16.0.172].onJoin
	[DD]	Level 4: 'join', channel[#bsdports].onJoin

[DD]	Level 1: 'data-available', server[172.16.0.172].onDataAvailable
	[DD]	Level 1: 'rawdata', server[172.16.0.172].onRawData
data : ':eik_!~[e-mail] QUIT :Client Quit'
	[DD]	Level 2: 'parseddata', server[172.16.0.172].onParsedData
	[DD]	Level 3: 'quit', server[172.16.0.172].onQuit
	[DD]	Level 4: 'quit', user[eik_].onQuit

But *only*

[JOIN]	eik_ (~[e-mail]) has joined #bsdports

in the channel tab, no quit message and eik_ is still there.

Should I try -console or the tcpdump?

Comment 5

[James Ross]

Ok, thanks for that information. The JavaScript errors are probably closely
related to things not being right. :)

I've found that a lot of stuff won't show up if I use the step 2 mentioned, so
it might be an idea to try with -console and skip step 2 if you could.

The problem appears to be (for the JS errors) that the JOIN message source is
":eik!miau" which has no "@" in it, and thus is not valid as far as ChatZilla's
code is concerned. It then makes the assumption that JOIN messages have a valid
source, which in this case there isn't one.

According to the RFC, there is nothing wrong with the source ":eik!miau" but
it's quite hard to handle, since it has a nickname but no host, it's not
logically valid. :) I'll have to see what happens if we create a User object
with only a nick and username...

Comment 6

[Oliver Eikemeier]

(In reply to comment #5)
> Ok, thanks for that information. The JavaScript errors are probably closely
> related to things not being right. :)
> 
> I've found that a lot of stuff won't show up if I use the step 2 mentioned, so
> it might be an idea to try with -console and skip step 2 if you could.

This doesn't seem to work for me, I olny get `stdout directed to dynamic
console' twice, that's it.

> The problem appears to be (for the JS errors) that the JOIN message source is
> ":eik!miau" which has no "@" in it, and thus is not valid as far as ChatZilla's
> code is concerned. It then makes the assumption that JOIN messages have a valid
> source, which in this case there isn't one.

I patched miau to default to eik!miau@miau, and everthing works fine (including
the QUIT messages). Thanks!

> According to the RFC, there is nothing wrong with the source ":eik!miau" but
> it's quite hard to handle, since it has a nickname but no host, it's not
> logically valid. :) I'll have to see what happens if we create a User object
> with only a nick and username...

Most other clients, like XChat seem to be able to handle this. You might want to
try miau or muh yourself, they are available on sourceforge.

At least I have a workaround (patching the bouncer), so thanks for your help. As
far as I am concerned, I can live with that, but of course I am happy to do some
more debugging if this helps.

-Oliver

Comment 7

[James Ross]

(In reply to comment #6)
> This doesn't seem to work for me, I olny get `stdout directed to dynamic
> console' twice, that's it.

No worries, we got enough information from the log I think.

> Most other clients, like XChat seem to be able to handle this. You might want to
> try miau or muh yourself, they are available on sourceforge.
> 
> At least I have a workaround (patching the bouncer), so thanks for your help. As
> far as I am concerned, I can live with that, but of course I am happy to do some
> more debugging if this helps.

Yeah, I'll look into coping with this (didn't expect you to be able to just
patch the proxy yourself, though). We should be able to cope with a User object
without a host, in which case it's easy to fix. :)

Thanks for the data, it has been most helpful.

Comment 8

[James Ross]

(In reply to comment #5)
> According to the RFC, there is nothing wrong with the source ":eik!miau"

Hmm. According to http://www.irchelp.org/irchelp/rfc/rfc2812.txt the BNF for
prefixs is this:

  prefix  =  servername / ( nickname [ [ "!" user ] "@" host ] )

Thus, "foo!bar" is actually invalid by this rule (or at least not valid for a
nickname prefix). This is a change from the original IRC RDF 1459, where both
!user and @host were optional, but either could occur without the other.

I've done a patch in bug 261270 that sorts out this bug, anyway.

Comment 9

[James Ross]

Since bug 261270 is FIXED, I believe this bug is also FIXED.

If this is not correct, please re-open stating why.