263185 - Trying to join +foo joins #+foo instead

Status: RESOLVED FIXED

(Other Applications :: ChatZilla, defect)

Description

[sk]

User-Agent:       Mozilla/5.0 (X11; Linux i686; U) Opera 7.23  [en]
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803

With Chatzilla 0.9.65 the URL irc://irc/+foo will take you to the channel #+foo 
instead of +foo.  With 0.9.61 the URL will take you to +foo as expected.

This bug also appears if you tell mozilla to run the command "join +foo" when 
connecting to the irc network.  It joins #+foo instead.

Reproducible: Always
Steps to Reproduce:
1. Create a shortcut on your desktop "mozilla.exe --chat irc://irc/+cti"
2. Open the shortcut


Actual Results:  
Opened channel #+foo

Expected Results:  
Opened channel +foo

Comment 1

[James Ross]

What server? I bet it's not advertising that it supports + channels, and thus
the behaviour is exactly as expected. Correcting really bogus summary.

Comment 2

[sk]

The irc server is a default debian ircu installation.  Looking through the
documentation and google I don't see anything about advertising + channels.

If you can give me more information I can look into this.  Thanks.

Comment 3

[James Ross]

If you could connect to the server with ChatZilla, and issue the command
"/supports" on that server's view, and then paste the entire reply into a comment.

Comment 4

[sk]

[INFO]	Supported channel types: +, #, &
[INFO]	Supported channel modes (A: lists): b
[INFO]	Supported channel modes (B: param): k
[INFO]	Supported channel modes (C: on-param): l
[INFO]	Supported channel modes (D: boolean): i, m, n, p, s, t
[INFO]	Supported channel user modes: o (@), v (+)
[INFO]	This server DOES support: cnotice, cprivmsg, rpl_isupport, userip,
wallchops, whox
[INFO]	This server DOESN'T support:
[INFO]	Server settings/limits: casemapping=rfc1459, chanmodes=b,k,l,imnpst,
channellen=200, chantypes=+#&, charset=rfc1459, chidlen=5, kicklen=160,
maxbans=30, maxchannels=10, modes=6, network=Undernet, nicklen=9, prefix=(ov)@+,
silence=15, topiclen=160

Comment 5

[James Ross]

Interesting... that does include + in the list. I'm suprised it's listed
*first*, though (which makes it the default for things with no recognised prefix).

Oooh, I think I see what you've done. You've got the join in autoperform, and
the IRC URLs are being done when it's not connected... right.

Hmmm, the autoperform we /could/ move to after the connect it actually done...

Comment 6

[sk]

Even if the auto-perform is empty, the problem still occurs.

I'm now on a different machine (Mozilla/5.0 (X11; U; Linux i686; en-US;
rv:1.7.3) Gecko/20041001 Debian/1.7.3-3) with Chatzilla 0.9.65 (0.9.61 still
works fine):

$mozilla --chat irc://irc/+foo,isserver
 
and I end up in channel #+foo.

Comment 7

[:Gijs (he/him)]

(In reply to comment #1)
> What server? I bet it's not advertising that it supports + channels, and thus
> the behaviour is exactly as expected.

I recently had a similar problem with a channel simply named "*" (don't ask me
why, but there were 10 people in it, according to the channel list CZ returned).
The support only listed the channeltype "#". So doing '/join *' joined channel
#* (which was empty, except for me). 
Someone adviced me to do /raw join <channelname>, but this returned 
===	* No such channel
Does anyone have a clue what's happening here? How come the channel is listed
but returns 'no such channel' on a join attempt?

Comment 8

[James Ross]

(In reply to comment #7)
> I recently had a similar problem with a channel simply named "*" (don't ask me
> why, but there were 10 people in it, according to the channel list CZ returned).

This is a private (+p) channel. Unlike secret (+s) channels, private channels
will appear in /whois and /list, except they will be named '*' (and probably
show no topic).

Comment 9

[Samuel Sieb]

I can't find a server that supports + channels.  Could you point me to one, or open yours and tell me by irc or email where it is?

Comment 10

[sk]

I'm using the debian package of ircu 2.10.10.pl18-4 on debian woody, as my company's private irc server. 

Comment 11

[James Ross]

No server is needed to fix it, though one may be to test :)

http://lxr.mozilla.org/seamonkey/source/extensions/irc/xul/content/commands.js#2171 just needs changing to always allow for the IRC URL specified prefixes (the 4 normal ones, IIRC). It can be left to check the server's list if it isn't one of the standard 4.

Comment 12

[James Ross]

(note that this problem will only occur when the server/network must be connected to fulfill the join request)

Comment 13

[sk]

I'll test any patches on my server.  As well I might have time to try a patch myself next week, if commands.js#2171 is the only place I have to worry about.  Thanks.

Comment 14

[:Gijs (he/him)]

Attachment: Patch

Patch for this. Note that gotoIRCURL also needed a change to make this actually work well.

Comment 15

[James Ross]

Checked in --> FIXED.