Last Comment Bug 303631 - IRCX ONJOIN messages (invalid source)
: IRCX ONJOIN messages (invalid source)
Status: RESOLVED FIXED
[ircx][cz-0.9.81]
:
Product: Other Applications
Classification: Client Software
Component: ChatZilla (show other bugs)
: Trunk
: All All
: -- enhancement (vote)
: ---
Assigned To: James Ross
: Samuel Sieb
:
Mentors:
irc://chat.psionics.net/JP_Drafting
Depends on:
Blocks: 314469
  Show dependency treegraph
 
Reported: 2005-08-05 17:26 PDT by Raymond Danner III
Modified: 2008-01-20 02:18 PST (History)
2 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Support PRIVMSGs the same as NOTICES (2.17 KB, patch)
2008-01-19 04:30 PST, James Ross
gijskruitbosch+bugs: review+
Details | Diff | Splinter Review

Description Raymond Danner III 2005-08-05 17:26:55 PDT
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.)
Comment 1 James Ross 2005-08-06 09:57:29 PDT
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
Comment 2 Raymond Danner III 2005-08-06 20:02:31 PDT
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. :)
Comment 3 James Ross 2005-08-06 20:19:45 PDT
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.
Comment 4 :Gijs Kruitbosch 2005-08-07 04:08:54 PDT
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)
Comment 5 James Ross 2008-01-11 01:23:53 PST
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.
Comment 6 James Ross 2008-01-19 04:30:33 PST
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 7 :Gijs Kruitbosch 2008-01-19 04:56:40 PST
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?
Comment 8 James Ross 2008-01-20 02:18:46 PST
Yes, this fixes the reported bug as best I can test (by injecting raw data into the processing pipeline).

Checked in --> FIXED.

Note You need to log in before you can comment on or make changes to this bug.