303631 - IRCX ONJOIN messages (invalid source)

Status: RESOLVED FIXED

(Other Applications :: ChatZilla, enhancement)

Description

[Raymond Danner III]

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]

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]

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]

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 (he/him)]

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]

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]

Attachment: 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 (he/him)]

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]

Yes, this fixes the reported bug as best I can test (by injecting raw data into the processing pipeline).

Checked in --> FIXED.