416966 - Audit use of unicodeName/encodedName so ChatZilla "works" even if with the wrong charset

Status: NEW

(Other Applications :: ChatZilla, defect)

Description

[:Gijs (he/him)]

As in summary. Follow bug from bug 242068. cmdJoin should be alright after that, now for the rest of the codebase...

Comment 2

[Robert Utasi [:hunboy]]

First situation:

If I use UTF8 mode and when joins an user with nickname contains national characters (ANSI,ISO), it makes some troubles:

Tested in UTF-8 and in ISO-8859-2
---
when chatzilla is in UTF-8 mode, it shows this:

úser ((null)@(null)) has joined #room

and shows leaving the room correctly almost every time.
quit the server is buggy in this case, user stays on the list, although gone
for a while. I need leave the room and rejoin to make clean the dead nicks out from the userlist.
---
when it is in ISO-8859-2 mode, it shows this:

úser ([e-mail]) has joined #room

so looks good, parting, quiting looks ok
---
but both of cases PrivMSG does NOT work at all, says:
The nickname “úser” does not exist.

same situation in ISO-8859-1 mode also.

If I set the server to ISO as well (not only the room), joining,parting, privmesg looks ok, but user's messages are totally unreadable by UTF reasons.

for test being úser suggested to use mirc6.35 thats in ANSI,ISO basically

Comment 3

[Robert Utasi [:hunboy]]

Attachment: join channel dialog box screenshot

channel dialog box sample (image-screenshot):

everything depends on the ircd server, the name is just a binary data (string).

server has 2 rooms, both of them are valid, existing, just one of them is ISO room, and the other one is UTF room.

this showing (when chatzilla is in UTF mode) is correct.

in this case, if i click one of them, always joins to the UTF room, and never joins to the ISO room.

Comment 4

[Robert Utasi [:hunboy]]

Situation 2:

Chatzilla is in UTF-8 mode

When the úser (ISO) sends a message to the room, his nick next to the message is clickable for privmsg.

This link contains this:
irc://192.168.1.160/%c3%baser,isnick

But always opens this:
irc://192.168.1.160/%c3%83%c2%baser,isnick

and we get this message:
=== The nickname “úser” does not exist.

so this is a bug in the bug, double UTF transformation

at the moment (because this is an ISO user) this link can be:
irc://192.168.1.160/%faser,isnick

but using this via browser, always opens this:
irc://192.168.1.160/%c3%baser,isnick

---

On the userlist: all of nicks are clickable for privmsg.
in this case always opens this:
irc://192.168.1.160/%c3%baser,isnick

although this is still an ISO user.

Comment 5

[Robert Utasi [:hunboy]]

Situation 3:

when the úser (ISO) sends me a privmsg

this query opens to me:
irc://192.168.1.160/%c3%baser,isnick

with this message:
=== The nickname “úser” does not exist.

and the current privmsq is showing to me in the server window:

from(úser) test

Comment 6

[Robert Utasi [:hunboy]]

(In reply to comment #5)

forgot:

the clickable link for the úser in the server window looks correct:
irc://192.168.1.160/%faser,isnick

but always opens this:
irc://192.168.1.160/%c3%baser,isnick

with this message:
=== The nickname “úser” does not exist.

Comment 7

[Robert Utasi [:hunboy]]

Command line situation:

Typing anything to command line,
perhaps /query nick, /join #channel always depends on the client's charset.
So in this case there is nothing to do, this will be always unstable, except if the user knows and applies the server used original binary string for the name.

The situation is different, when the user uses built in tools, perhaps join-channel-dialog-box or clickable nicknames in rooms or the server window.
In this case chatZilla always can know the original binary string (because those came from the server), so should generate a correct command to the server.

The ISO úser to the ircd server simply means 0xFA73657200 which is never equivalent to 0xC3BA73657200

so my idea (suggestion) is: always use the original binary string (came from the server) during link (URLencoded of course) or command generating. Or accepting a valid URL from the browser without transformation. (invalid URL with non7bit characters is a different case)

Comment 8

[Robert Utasi [:hunboy]]

1 more problem left at the moment:

If there are 2 users (channels) 1 ISO and 1 UTF with same unicodeName, and the user (channel)-identification based on unicodeName instead of original string, is always unstable