Closed Bug 285151 Opened 19 years ago Closed 19 years ago

Nickname changes not updated in userlist (cz0.9.67)

Categories

(Other Applications :: ChatZilla, defect)

Product:
Other Applications
Component:
ChatZilla
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 278900

People

(Reporter: tripple_moon_3m, Assigned: rginda)

Details

(Whiteboard: DUPME) 

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1

When a user changes nick while in a channel the nick is not updated in the
userlisting.

Reproducible: Always

Steps to Reproduce:
1. join a server
2. change nick.


Actual Results:  
Nick was not updated in userlisting.

Expected Results:  
obviously you would expect it tobe updated acoardingly, like in previous versions.
errr seems i left out an obvious set in reproduction steps:
1.5) join a channel
Worksforme. 

Unless you provide more information this is not exactly a useful bugreport,
since it works for lots and lots of other people, and so far you've been the
first to report this problem as specific to 0.9.67. The people who previously
reported a problem like this (over the whole of CZ) usually found out it was an
issue on their side, so unless you give specific information we can only assume
this is a specific issue to do with you as a user not configuring things properly.

Have you even tried to reproduce this bug on other servers and/or channels?
What server and channel did this problem occur on?
Do you still get a normal notice in the view itself that your nickname has changed?
Has your nickname changed next to the input box?
Have you verified that your nickname actually changed? (ie, there wasn't
something on the server that stopped you from doing so)

Ok fair enough ill try answering those questions you got.
"Have you even tried to reproduce this bug on other servers and/or channels?"
To be honest no, didnt have time todo so yet.

"What server and channel did this problem occur on?"
irc://irc.usrv.de/Core but also other channels on this server.

"Do you still get a normal notice in the view itself that your nickname has
changed?"
No response IIRC for myself..
No response for others definitly.

"Has your nickname changed next to the input box?"
I seem tobe unable to change nicks atm.

"Have you verified that your nickname actually changed? (ie, there wasn't
something on the server that stopped you from doing so)"
I just tried my own nick and could not. (im half operator with registed nicks)

But other ppl who changed were still listed as the name they got in but when
they type text the text is displayed with their new nick in chat view.

I know for a fact that the previous version which i started with after download
didnt had this bug.
I updated once to current version and things were like im telling.
I had DL'ed from the FireFox extensions page.
I have since the bug updated FF to v1.0.1 from previous version, and still have
same problem.

If you need more info/feedback just ask.
Still a worksforme, I can change my nickname fine on that server and in that
channel. Did you mess with any settings concerning character set?
Nope i didnt.
Hrm, what was the version you had before? And could you please try to reproduce
this on other servers (like, for instance, irc://irc.mozilla.org/ )

Hmmmm now im realy dazzled....
Seems it works there.
I just logedin that server joined #Firefox, and changed nick 2x.
Both times it seemd to both give me a nick change msg back and reflected it in
the user listing.
Could it be todo with registered nicks or user status?
Im completely blank because of this...

PS: I use startup commands on the server i mentioned. perhap that had todo wirh ir?
I also use a hyperlink on a webpage to enter the server.
The commands are in sequence:
msg NickServ AUTH <code>
msg nickserv ghost [EC]TriMoon <password>
msg nickserv ghost [EC]TriMoon|afk <password>
msg nickserv ghost [EC]SV|TriMoon <password>
nick [EC]SV|TriMoon
msg NickServ IDENTIFY <password>
list
msg NickServ listlinks
join #Core
join #Market

PPS: I just noticed while in settings that "Character encoding" is set to
"utf-8" on all servers, also if I create a new one.
I dont know if this is the default on others also, but it is on mine...
(In reply to comment #7)
> PPS: I just noticed while in settings that "Character encoding" is set to
> "utf-8" on all servers, also if I create a new one.
> I dont know if this is the default on others also, but it is on mine...

That's the overall default, it's normal.

I would still like to know what version of ChatZilla you were using when
changing your nickname on that server *did* work. I'd also like to know if you
still get a nick message for that change you do using the commands you run on
startup (nick [EC]SV|TriMoon) and if you do get a nickname message when you
change your nick before joining those channels.

Thanks for helping out :-).
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #8)
> I would still like to know what version of ChatZilla you were using when
> changing your nickname on that server *did* work. I'd also like to know if you
> still get a nick message for that change you do using the commands you run on
> startup (nick [EC]SV|TriMoon) and if you do get a nickname message when you
> change your nick before joining those channels.
> 
> Thanks for helping out :-).
> 
I cant provide version, but it was latest before the current one as i mentioned.
I didnt get nick change messages using those commands.
I cant give feedback on nick changes anymore because all channels are now
restricting nick changes :D
But a similar effect i noticed is that i seem not to get channel mode displayed
until i do a manual "/mode #Channelname" after being in the channel using those
cammands.
Maybe it is related....

Could you paste in the output of the following command, when run on the server
you are using:

  /supports

I have suspicions this is a particularly vicious, known bug that only affects
particular servers and particular nicks.
(In reply to comment #10)
> Could you paste in the output of the following command, when run on the server
> you are using:
> 
>   /supports
> 
> I have suspicions this is a particularly vicious, known bug that only affects
> particular servers and particular nicks.

irc.usrv.de
	[INFO]	Messages Cleared.
	[INFO]	Supported channel types: #
	[INFO]	Supported channel modes (A: lists): b, e, q, a
	[INFO]	Supported channel modes (B: param): k, f, L
	[INFO]	Supported channel modes (C: on-param): l
	[INFO]	Supported channel modes (D: boolean): p, s, m, n, t, i, r, R, c, O, A,
Q, K, V, G, C, u, z, N, S, M, T
	[INFO]	Supported channel user modes: o (@), h (%), v (+)
	[INFO]	This server DOES support: hcn, knock, map, rpl_isupport, safelist, wallchops
	[INFO]	This server DOESN'T support:
	[INFO]	Server settings/limits: awaylen=307, casemapping=ascii,
chanmodes=beqa,kfL,l,psmntirRcOAQKVGCuzNSMT, channellen=200, chantypes=#,
chidlen=5, elist=MNUCT, extban=~,cqnr, kicklen=307, maxbans=60, maxchannels=30,
maxtargets=20, modes=12, network=UsrvIRC, nicklen=30, prefix=(ohv)@%+,
silence=15, topiclen=307, watch=128

PS: as of now i have left the game and IRC server so i cant supply more info sry.
... casemapping=ascii ...

Yes, this is the known issue with casemapping (I hate some bits of the spec).
Anything you do before the 005 message has to assume the default case mapping
(the rfc mode), which turns [] into {} for canonicalisation. It doesn't always
matter, but I think it will hurt you if your nickname uses those characters
*and* you join some channels before the 005.

I'll find the dup later...
Whiteboard: DUPME
Could you wait for the 005 before joining any channels?  Is it guaranteed to be
sent?
Unfortunately not, as even in the newer IRC spec it is defined as this:

  005    RPL_BOUNCE

...and using it as RPL_ISUPPORT is mearly a de-facto extension.

However, we could try delaying all of our automatic-fu until we get either
RPL_ENDOFMOTD or ERR_NOMOTD, because one of them is gurenteed to occur according
to the spec (and 005 will be sent way before the MOTD).
(In reply to comment #14)
> Unfortunately not, as even in the newer IRC spec it is defined as this:
> 
>   005    RPL_BOUNCE
> 
> ...and using it as RPL_ISUPPORT is mearly a de-facto extension.
> 
> However, we could try delaying all of our automatic-fu until we get either
> RPL_ENDOFMOTD or ERR_NOMOTD, because one of them is gurenteed to occur according
> to the spec (and 005 will be sent way before the MOTD).

Maybe, but I'd really like the motd parsing to be faster in that case (or it
will really delay joins), if possible (maybe parse it in one go instead of
display it line by line?)
Currently I thought the very reason that everything goes before the MOTD is just
to make them quicker.
To be honest, I think the extra work of trying to run auto-perform and the
auto-join stuff right when we start getting the MOTD is why it is as slow as it
is - that and Gecko itself is pretty slow.

We could try buffering each MOTD line internally, and when we get the
RPL_ENDOFMOTD we un-buffer it, and run the auto-fu.

Only way to tell what affects it is to try it, really. Also need to watch out
for the skip MOTD flag we have somewhere...
Duped to 278900. Both are about casemapping not being rfc1459 breaking things,
as far as I'm aware, and both should be fixed by the patch on that bug. If
anyone disagrees, please reopen.

*** This bug has been marked as a duplicate of 278900 ***
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.