Forums Bug Reports Multiple Modes Glitch

I've been testing several IRC clients and servers on this and I am getting this glitch everywhere I go. I have also asked this question to the Unreal IRC development team but I wander why this bug / glitch appears and how it should be handled (on the server or on the client-side).

It works as follows:
- User1 joins an irc server and makes a channel.
- User1 now has operator status on this channel.
- User1 does a MODE +v on the channel and himself. This will make him have a second-status as voice.
- User2 now joins the channel made by User1.
- User1 deops himself (he will have voice-status on the server).
- User1 now sees the + sign (for voice) in front of his nickname in the nicknames-list.
- User2 does not see this prefix in front of the nickname of User1.

When User2 does a WHOIS on User1 mIRC will see that this user has voice-status on the channel but will not correct the prefix in the nicklisting.

When User2 does a NAMES on the channel mIRC will silently fix it and add the + prefix in the nicklisting.

Is this an actual bug? And evenmore...is this a bug on the client or on the server-side? I've been checking both the IRC Protocol (rfc1459) and the IRC: Client Protocol (rfc2812) for an answer but none specify how multiple modes should be handled.

Anyone with an answer?

It's a design flaw in the original IRC protocol: a /names-reply only contains either a @ or a + prefix for a nickname (or neither, of course), but never both. From section 6.2 of RFC 1459:


I.e. the problem is inherent to the protocol, and neither IRC servers nor mIRC can do very much to solve it, at this point. Given the limited extra abilities that voice gives to people, the issue is considered to be not that important.

Well I actually do think this can be fixed at the client side by re-checking the names on a channel at the moment a user loses a mode.
So if an operator sets -<status> on someone the client *could* re-check the status of the targetted user. (Correct me if I'm wrong)

Weird thing is that the prefix will appear only when checking the channel-modes with a NAMES command and does not re-appear when checking the targetted nick with a WHOIS command.

In theory yes, but it's not a very good idea to do so. The IRC protocol does not allow you to query for the status of an individual on a channel, you'd have to for example do a /names for the whole channel again. On a large channel, and with a lot of deops, this would make you receive lots of information and possibly have the server disconnect you.

If you really want this feature, you can always script it. But in general the problem is not considered to be important enough to warrant a workaround like you suggest.


mIRC doesn't interpret the channels list in WHOIS replies. It would be messy to do so, as some IRC servers use that reply to indicate other things as well (such as the user having set a certain usermode, ircu does this with +d), making it very hard to parse it properly.

Nah, there is a specific server code associated with a channel reply from a whois.

Caveats:
- Server doesn't HAVE to use it
- May be multiple sent to split up the line if there are alot of channels

raw 319:*: {
; Whois result: channel list
}

There's your starting point.

You missed the point. I was already talking about parsing the 319 lines.