User Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Firefox/24.0 (Beta/Release) Build ID: 20140716183446 Steps to reproduce: Anything sent to a +channel, &channel, or any channel not beginning with a #, will show up in a private query with whoever sent the message, and a notice referencing the need to identify with services appears in the channel tab. Sending messages from ChatZilla to the channel works fine. Actual results: [INFO] This channel requires that you have registered and identified yourself with the network's nickname registration services (e.g. NickServ). Please see the documentation of this network's nickname registration services that should be found in the MOTD (/motd to display it). Expected results: Any messages received in any channel should of course appear in the channel, not in a query.
To figure out what's going on here, we're going to need the debug logging from ChatZilla when the problematic messages arrive. To enable this, follow these instructions: * Open "about:config" * Find the preference "browser.dom.window.dump.enabled" and set it to true ** If it doesn't exist, create a new Boolean preference of that name and set it to true * In ChatZilla, run the command "/pref debugMode t" (enabled tracing) * Close all Firefox windows, including ChatZilla * Start Firefox with the -console command-line switch, either by dragging the Firefox shortcut to the Run box (in Windows) or typing "firefox" in a console (in Mac/Linux) and adding " -console" to the end. ** You should get some messages in the console (usually a separate black window on Windows), if not try opening ChatZilla - that certainly logs some messages. If you still see nothing, one of the two preferences isn't working. * Execute whatever is needed in ChatZilla so that you experience the mishandled message. ** You should see around 5 or 6 lines in the console for each message that arrives in ChatZilla. Try and isolate the one relevant to the issue. * Afterwards, in ChatZilla, run the command "/pref debugMode -" (disabled tracing)
receiving privmsg in #channel cz: Level 1: 'rawdata', server[uploaddownload.pw].onRawData data : ':wowaname!^wowaname@volatile/oper/lolikaastbgo5dtk.onion PRIVMSG # :.' cz: Level 2: 'parseddata', server[uploaddownload.pw].onParsedData cz: Level 3: 'privmsg', server[uploaddownload.pw].onPrivmsg cz: Level 4: 'privmsg', channel[#].onPrivmsg receiving privmsg in +channel cz: Level 1: 'rawdata', server[uploaddownload.pw].onRawData data : ':chakra(urc)!chakra@qcubynns/cloak PRIVMSG +volatile :pong' cz: Level 2: 'parseddata', server[uploaddownload.pw].onParsedData cz: Level 3: 'privmsg', server[uploaddownload.pw].onPrivmsg cz: Level 4: 'privmsg', user[chakra(urc)].onPrivmsg
/supports returns Server settings/limits: awaylen=127, casemapping=ascii, chanlimit=#&+:420, chanmodes=beI,k,lr,imMnOPQRstVz, channellen=50, chantypes=#&+, charset=UTF-8, chidlen=5, excepts=e, invex=I, ircd=OG-IRCd, kicklen=400, maxchannels=10, maxlist=beI:50, modes=5, network=Volatile, nicklen=24, prefix=(yqaohvV)!~&@%+-, topiclen=490
Sorry, I overlooked the other lines... 21 13 20: [INFO] Supported channel types: #, &, + 21 13 20: [INFO] Supported channel modes (A: lists): b, e, I 21 13 20: [INFO] Supported channel modes (B: param): k 21 13 20: [INFO] Supported channel modes (C: on-param): l, r 21 13 20: [INFO] Supported channel modes (D: boolean): i, m, M, n, O, P, Q, R, s, t, V, z 21 13 20: [INFO] Supported channel user modes: y (!), q (~), a (&), o (@), h (%), v (+), V (-) 21 13 20: [INFO] This server DOES support: penalty, rpl_isupport 21 13 20: [INFO] This server DOESN'T support: 21 13 20: [INFO] Server settings/limits: awaylen=127, casemapping=ascii, chanlimit=#&+:420, chanmodes=beI,k,lr,imMnOPQRstVz, channellen=50, chantypes=#&+, charset=UTF-8, chidlen=5, excepts=e, invex=I, ircd=OG-IRCd, kicklen=400, maxchannels=10, maxlist=beI:50, modes=5, network=Volatile, nicklen=24, prefix=(yqaohvV)!~&@%+-, topiclen=490
Okay, so the problem is that we have a conflict between the channel prefixes and the user mode prefixes: both contain & and +. The ChatZilla code for handing NOTICE and PRIVMSG messages strips off up to one user mode prefix character from the target before routing it, hence treating the & and + channel messages as user messages. The code for stripping these prefixes was done in bug 330990 with my own amusing comment regarding checking which prefixes to strip: "I don't think it's worth validating anything with 005 in this particular case unless we run into problems." Well, we've run into problems, albeit nearly 9 years later. :) So I think the fix here is to parse STATUSMSG from 005 and only strip those prefixes (if any are set). The three networks I am on (moznet [InspIRCd], freenode [ircd-seven] and a private network [InspIRCd]) all have CHANTYPES=# (so no other channel types) and have STATUSMSG set to the same prefixes as PREFIX itself (user mode prefixes) so will continue to support the status prefixes, while the IRCd in this bug doesn't have STATUSMSG set at all so will stop stripping all user mode prefixes.
Couldn't op prefixes be stripped only in NAMES replies? That's the only place they are used and would cause much less complication in the meantime.
You misunderstand the feature this is supporting: this code exists for servers that support sending messages to channels with a usermode prefix, e.g. /msg @#chatzilla will send to all ops in #chatzilla. Such messages come through to the ops with the user mode prefix included, so we must strip it. As I said in comment 5, I think the fix is to make sure this stripping is only performed on servers that advertise the above feature with STATUSMSG in 005 and only for the user modes specified there.
It sends the op prefix in the notice/privmsg? I didn't know that part...
You need to log in before you can comment on or make changes to this bug.