User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6 Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6 Some IRC channels (see IRC link above as example with mIRC, then Chatzilla) use text that is sent on a person joining the channel. This text is /not seen/ by people using Chatzilla; the proper behavior is to show the text in the channel's window for the person who just entered. Reproducible: Always Steps to Reproduce: (Manual method) 1. Enter /server chat.psionics.net 2. /join #JP_Drafting Actual Results: The channel rules aren't echoed. Expected Results: These lines (sent by the server; see below) should be displayed: [hh:mm] <#JP_Drafting> Welcome to the Joint-Post Drafting Room! [hh:mm] <#JP_Drafting> RULES [hh:mm] <#JP_Drafting> 1 Please don't idle in the room; its purpose is to assist in writing. [hh:mm] <#JP_Drafting> 2 Please, if you are an observer and writing's happening, don't disturb (see 3). [hh:mm] <#JP_Drafting> 3 If you are invited to help, feel free to do so. (The text "[hh:mm]" will vary; it is the timestamp of the message time.)
The messages have an invalid source prefix, and are lost because of this. >> :#JP_Drafting PRIVMSG #JP_Drafting :Welcome to the Joint-Post Drafting Room! >> :#JP_Drafting PRIVMSG #JP_Drafting :%02RULES%02 >> :#JP_Drafting PRIVMSG #JP_Drafting :1 Please %1Fdon't%1F idle in the room; its purpose is to assist in writing. >> :#JP_Drafting PRIVMSG #JP_Drafting :2 Please, if you are an observer and writing's happening, don't disturb (see 3). >> :#JP_Drafting PRIVMSG #JP_Drafting :3 If you are invited to help, feel free to do so. The "#JP_Drafting" prefix is not valid according to the RFC, and means ChatZilla parses the messages as if they had no source (the prefix parsing fails to find anything that is valid, so just ignores it). Since it needs a source for all PRIVMSG messages, it actually gets an error processing the message, as can be seen from this debug log: Error routing event server.privmsg: + message (string) 'e.user has no properties' + fileName (string) 'chrome://chatzilla/content/lib/js/irc.js' + lineNumber (number) 2262+ stack (string) 315 chars + name (string) 'TypeError'* in onPrivmsgTypeError: e.user has no properties serv_privmsg([object Object]) chrome://chatzilla/content/lib/js/irc.js:2262 ep_routeevent([object Object]) chrome://chatzilla/content/lib/js/events.js:238 ep_stepevents() chrome://chatzilla/content/lib/js/events.js:306 mainStep() chrome://chatzilla/content/static.js:1503 [anoynmous] chrome://chatzilla/content/static.js:1505
This bug is caused by a failure to follow /all/ of the IRCX protocol extensions (RFC 1459). If this was something that wasn't standards-based, why does even Microsoft's own Chat program support IRCX? Chatzilla may not be the only IRC client that fails this particular situation, but the point is that it should not be failing. mIRC handles this situation fine... (displaying the rules as a properly-formatted set of private messages from the channel itself (sent by the server).) I am a member of the staff of chat.psionics.net, which is running IRCXPro. We at the chatnet want this problem fixed, please. :) Any questions, just look for Bynw (System Administrator/network founder) in #Myndworks. :)
Firstly, let me point out that RFC 1459 is the IRC protcol spec. IRCX is an extension to it, and I don't (off-hand) know its RFC number, if it has one. Secondly, I think IRCX was *designed*, *implemented* and *forced onto people* by Microsoft themselves. There is nothing that even suggests that a normal IRC client should support ANY of IRCX.
For the record, the draft as done by Dalen Abraham, a Microsoft employee, can be found here: http://www.ignition-project.com/ircxdraft/ As said, this extension is not part of RFC 1459, nor of the more recent RFC's 2811-2813. Therefor, this is not something we 'must' implement. We may choose to do so, and if so, this bug should be redone to: Summary: Support the IRCX extensions to the IRC protocol URL: see above Severity: Enhancement Though it seems that's what the reporter of this bug wants us to do, I'll leave this bug be for now. The reporter can decide whether or not I deduced his intentions correctly. In this state, the bug is valid and can be confirmed. Whether ChatZilla will actually implement the extensions is not up to me, but at least it will get this bug in order. Lastly, I'd suggest that the reporter of this bug starts using an IRC server that adheres to RFC1459, even when sending welcome messages. The IRCX draft clearly specifies that it should in no way stop clients from using the server if they do not support the extensions. The way you use this server violates this principle, as some users don't get (important) messages because you use the extensions system to send them. Consider simply using a user bot, like nickserv or chanserv, which is perfectly capable of taking care of these messages. (Yes, I know this is not specified in any RFC's, but at least it will *work* with any normal IRC client)
A quick experiment suggests that IRCX ONPART messages, which are sent similarly to ONJOIN but using NOTICE and the user as the target, 'work' because we already allow for NOTICEs without a valid source.
Created attachment 297945 [details] [diff] [review] Support PRIVMSGs the same as NOTICES This makes our handling of PRIVMSGs the same as for NOTICES. Two new behaviours: - If there is no valid source and the target is a channel (e.g. IRCX ONJOIN), we display it in the channel with "===" in the source column and msg-type= PRIVMSG. - If there is no valid source and the target is a user, we just display it on the network view. I dunno if we're ever likely to get this, but it's worth being safe.
Comment on attachment 297945 [details] [diff] [review] Support PRIVMSGs the same as NOTICES r=me PS: so this entirely fixes the bug as reported, right?
Yes, this fixes the reported bug as best I can test (by injecting raw data into the processing pipeline). Checked in --> FIXED.