363752 - Using a nickname that fails to decode properly confuses who-am-I code

Status: NEW

(Other Applications :: ChatZilla, defect)

Description

[:Mook]

Err, this might be a "don't do that", not sure.  Steps to reproduce:
1) Attach to irc.net.cn or some other server using GBK as the nick charset.
2) Use UTF-8 for the network view (this is by default, so just do nothing)
3) Attempt to use a nick that has an odd number of bytes when expressed in UTF-8 (I just used "/nick ー")
4) Join any channel. (in my case, "/join testing-please-ignore")

After step 3, CZ thinks my nick is some sort of empty string.  I think this is because: (Ethereal dump; the UTF8 has been escaped into octal:)

# this is CZ sending the nick request
Request: NICK \343\203\274
# this is IRCd replying
Response: :Mook!mook@<my IP> NICK :\343\203

# joining the channel
Request: JOIN #testing-please-ignore
# and getting in...
Response: :\343\203!mook@<my IP> JOIN :#testing-please-ignore
Response: :hub.irc.net.cn 353 \343\203 = #testing-please-ignore :@\343\203
Response: :hub.irc.net.cn 366 \343\203 #testing-please-ignore :End of /NAMES list.

Expected results:
Err, possibly telling me that this is a bad charset for the network view.  Or maybe giving me a warning about a bad nick or something.

Actual results:
The join keeps spinning, and it tells me "(null)((null)@(null)) has joined"... :)

Comment 1

[James Ross]

The summary of this bug conflicts with comment 0. As it stands, the summary is INVALID; comment 0 is basically BECAUSEIRCSUCKSBALLS. ;)

Comment 2

[Samuel Sieb]

Why can't chatzilla detect that the returned nick is different and use what is returned (with a message maybe if it's different than expected)?

Comment 3

[James Ross]

It *is*. It's decoding it as UTF-8 and that's failing because it's not valid UTF-8.

Comment 4

[Stephanie Daugherty [:sdaugherty]]

RFC2812 and RFC1459 both define the protocol as using 8bit characters therefore behavior of IRC clients and servers with multibyte characters is itself undefined, and expecting consistency when using different wide character sets on the client and server is beyond reasonable.

Comment 5

[Stephanie Daugherty [:sdaugherty]]

Confirming this, it's clear there's a problem although it's not clear what behavior would be sane here...

Comment 6

[James Ross]

Indeed; this is why the IRC library code keeps a copy of what the server calls something separately from what ChatZilla shows (unicodeName vs. encodedName properties). The problem here is likely that it's updating the nickname from the Unicode version, and thus ends up with the wrong encoded name. This then means it can't tell what commands are for itself or someone else.

At minimum, the IRC library code *must* keep the correct encodedName to continue functioning; what we do in the front-end (i.e. what nick we display) and whether we tell the user something's "not quite right" is another matter.

Comment 7

[clogged.drainpipe]

Is this issue still relevant? If not, it should be closed.