278900 - nick with ^ character + unrealircd = broken headers and broken nick changes

Status: RESOLVED FIXED

(Other Applications :: ChatZilla, defect)

Description

[Michael Mason]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

when chatizlla is started with a nick that contains the caret ^ character,
connecting to any server that runs the Unreal-IRCD results in all channel
headers displaying "<unkown>" instead of the appropriate information.  also,
'quit' messages seem to be missing in this situation, simply gone.  also, when a
"/nick newnick" command is issued in this situation, the nick on the server is
changed, but the user's nick does not *appear* to change at all within the
chatzilla UI.

i have tested this with unreal-ircd and several non-unreal ircds and the only
one that seems to reproduce these symptoms are those running unreal.  i have
reproduced this on multiple systems on multiple connections with multiple unreal
servers.

Reproducible: Always

Steps to Reproduce:
1. set nick that is associated with an Unreal-IRCD server to something that
contains the ^ character, such as IRC^Monkey
2. restart chatzilla
3. connect to the server you just associated that nick with
4. join a channel

Actual Results:  
1. headers contain "<unknown>" instead of appropriate information
2. nick changes appear to not take effect, when they actually do
3. quit messages are not displayed

Expected Results:  
1. displayed header info properly
2. display nick changes properly
3. display quit messages properly

Comment 1

[James Ross]

What versions of UnrealIRCd and ChatZilla did you use/try? Also, did you have
the channels on auto-connect (so they join automatically when connecting to the
server), or did you simply do /join after connecting?

UnrealIRCd prior to 3.2 (IIRC) has a rather well know, serious bug which could
easily cause this kind of problem.

In particular, you can test for this bug as follows:

- connect with a nickname like "nick^"
- do "/whois nick^"
- do "/whois nick~"
- do "/supports" and note the value associated with 'CASEMAPPING'

If CASEMAPPING is ASCII or STRICT-RFC1459, the second /whois should fail. If
CASEMAPPING is RFC1459, then both /whois commands should work. Any other
combination means the server has a bug.

Comment 2

[:Gijs (he/him)]

Attachment: Patch to correct all canonicalName-s if we have a non-default casemapping

Update all the keys for channels and users, and update their canonicalnames, so
they all correspond to expected values based on the casemapping.

Comment 3

[James Ross]

Comment on attachment 183539 [details] [diff] [review]
Patch to correct all canonicalName-s if we have a non-default casemapping

review- since I missed the fact foreach...in, as cool as it is, is new. Change
to use for...in.

Comment 4

[:Gijs (he/him)]

Attachment: Patch to use normal for loops

Patch to use normal for loops instead of foreach

Comment 5

[James Ross]

Comment on attachment 183666 [details] [diff] [review]
Patch to use normal for loops

Looks good; could have used an intermediate for |this.channels[channel]|.

r=silver (with or without the intermediate)

Comment 6

[:Gijs (he/him)]

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

Comment 7

[James Ross]

Checked in -> FIXED.

I *think* this is fixed by the patch, but please test the 2005-07-02 nightly on
http://twpol.dyndns.org/mozilla/chatzilla/nightly/ (when it updates in 25
minutes) to see how much has really been fixed.