IRC server port specification seems to not work...



Other Applications
16 years ago
13 years ago


(Reporter: Chris P. Ross, Assigned: Robert Ginda)


Firefox Tracking Flags

(Not tracked)




(1 attachment, 1 obsolete attachment)



16 years ago
If I try to use a bookmark that's set to the above URL, it will try to
connect to the right server, but to port 6667.  This is clearly not
what the URL intended.  Is this known broken?
This is chatzilla 0.8.5 on mozilla 0.9.7 on BSD/OS.

Also, if I try: "/server irc://" in an
open chatzilla window, it tries to connect to irc://irc/ (port 6667).
This is even *more* wrong.

Should this be two bugs?  Am I doing something wrong?

Comment 1

16 years ago
You have a very old build, please try with a newer one, either 0.9.9 or a nightly.

Comment 2

16 years ago
K.  Thought that might be related, but wasn't sure.  I'll have a 0.9.9 to
test against soon...

Comment 3

16 years ago
It's even worse with 0.9.9.  If I try to go to that URL, it simply pops
up a dialog box saying:

i is not a registered protocol.


Comment 4

16 years ago
Actually, it's worse than that.  Doing the same process of "Install 0.8.5" from
the chatzilla page on hackrus [as root], it says it installed successfully,
and I should restart.  Which I did, again as root, to allow it to register.
I then exited, and started it up as myself.  Now the 'IRC Chat' is in the
Tasks menu, but when I start it up, it brings up a chatzilla window with no
tabs, and it doesn't ever process any input I give it in the bottom text input
Seems to be totally broken.  But, it worked just fine (sans the mishandling
of URL's) under 0.9.7.
Is this expected to work right under 0.9.9?  Any idea what may be wrong?

Comment 5

16 years ago
Chris, for your first problem, delete component.reg.  For the second one, 0.8.5
is too old and doesn't work with recent builds.

Comment 6

16 years ago
- I'll try nuking components.reg and see what that changes.  Thanks...
- Well, you suggested I try it with 0.9.9 or a newer build.  Is there someplace
I can get a newer chatzilla than 0.8.5?  That's the newest one I see...

Comment 7

16 years ago
I deleted component.reg, and ran mozilla as root (to re-register everything,
which listed registering -chat handler).  When I then run it again as myself,
I get the same behaviours, on all counts.  The dialog from the attempt to
use the bookmark, and a mostly non-functional chatzilla if I call it up
on it's own.
Will wait for more information on getting a chatzilla that works better in
0.9.9.  Thanks.

Comment 8

16 years ago
The problem is you messed up chatzilla by installing an old version over it. 
Try re-installing 0.9.9 and it should work (you may need to delete component.reg).

Comment 9

16 years ago
rginda just pointed out to me that the latest chatzilla.xpi is available at:
(yes, windows-xpi is ok, because chatzilla is not platform-dependant)
You can just click that link and it will install.

Comment 10

16 years ago
Okay.  Thanks.  With that XPI, I'm back to the previous state.  chatzilla
comes up and works okay, and the bookmark will now invoke chatzilla once again,
but it displays the same problems.  Going to a bookmark with the above URL
as it's target fails upon repeated attempts to open
There's still a port parsing problem in there somewhere.
This is with:
Chatzilla 0.8.6 [Mozilla/5.0 (X11; U; BSD/OS i386; en-US; rv:0.9.9) Gecko/20020312]
I'm seeing the same thing. Doing /attach irc:// gives
"Connecting to via, attempt 1 of 5...".
The problem seems to be that onInputServer
can't handle the string that it gets from
The port seems to end up in ary[4]. I don't really understand that regexp in
onInputServer, so I'm not sure how to fix it.
OS: BSDI → All
Hardware: PC → All

Comment 13

16 years ago
Created attachment 75293 [details] [diff] [review]
Patch to regex in cli_iserver (handlers.js:1410)

Okay.  I did a little research on how JS regex's work, and figured out what the
problem is.  Or at least, know what's going on.
is calling onInputServer with 'host port pass'.  So, in the case that there's
no pass, it gets (for above URL) " 23508 " (note the
trailing space).  It's this trailing space that isn't accounted for in the
Assuming it wouldn't be better to do some sort of more drastic re-think about
the parameter in question, simply making the change I'm attaching allows for
one space to trail the port number in the case that there's a port number and
no pass.  The space is absorbed otherwise as a separator in the case that there
is a pass in the inputData.
This solution look reasonable to folks?

Comment 14

16 years ago
The added \s? (maybe match one space) should probably be \s* (match 0 or more
spaces), but other than that it sounds reasonable to me.  That's a hideous
regex, and the server command has *no* reason to accept so many parameter
formats, but it'll all be ripped out when the command manager lands.  In the
mean time, I think we should check this in for 1.0 to get ports in urls working

Comment 15

16 years ago
Created attachment 75317 [details] [diff] [review]
updated patch with rgrinda's suggestion

Okay.  I'm good with that.  I thought about that originally, but thought it
might "loosen" the constraints on the regexp matching of the parameter too
much.  But
if it's gonna all be replaced anyway, then it can't matter much.  If you're
good with it, I am.
And I whole-heartedly agree that we should get this committed soon, ie before
1.0. (or whatever the next bundled milestone is)
Attachment #75293 - Attachment is obsolete: true
Comment on attachment 75317 [details] [diff] [review]
updated patch with rgrinda's suggestion

Attachment #75317 - Flags: review+

Comment 17

16 years ago
Comment on attachment 75317 [details] [diff] [review]
updated patch with rgrinda's suggestion

a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #75317 - Flags: approval+

Comment 18

16 years ago
checked in, thanks for the patch.
Last Resolved: 16 years ago
Resolution: --- → FIXED
Product: Core → Other Applications
You need to log in before you can comment on or make changes to this bug.