DCC functionality in ChatZilla isn't functional.

RESOLVED FIXED

Status

Other Applications
ChatZilla
RESOLVED FIXED
12 years ago
12 years ago

People

(Reporter: David Barr, Assigned: Gijs)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [cz-0.9.69.1])

Attachments

(3 obsolete attachments)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20051121 SeaMonkey/1.5a
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20051121 SeaMonkey/1.5a

No ports have been specified in the Preferences pane.

+++++

DCC receive:

[18:54:19]	sid^^	DCC Send Baby Seal face.jpg (12.39.92.135)

/dcc-accept sid^^

[18:54:22]	[INFO]	0 pending incoming DCC offers matched.
[18:54:22]	[INFO]	You must specify enough of the user's nickname to uniquely identify the request, or include the request type and even the filename if necessary.

+++++

/dcc-send sid^^

{File browser comes up. Select a small .jpg.}

[ERROR]	Internal error dispatching command “dcc-send”.
[ERROR]	TypeError: setting a property that has only a getter @ <chrome://chatzilla/content/handlers.js> 2562

+++++

/dcc-chat sid^^
[19:02:06]	[DCC]	Sent DCC Chat offer to “sid^^” from YOU (67.186.207.96:55938) [Cancel].

[19:05:06][DCC]	Aborted DCC Chat with “sid^^” (67.186.207.96:55938).

+++

The FAQ (http://www.hacksrus.com/~ginda/chatzilla/faq/chatzilla-faq.html, Section 2.9) doesn't give any information about setting ports for DCC, or troubleshooting. If you have anything you want me to check, let me know. Next week, I will have a chance to test through a different ISP.



Reproducible: Always

Steps to Reproduce:
1. Perform any dcc function.

Actual Results:  
Note that the function fails.

Expected Results:  
Sends, receives, and chats should connect.
(Reporter)

Comment 1

12 years ago
[INFO]	Chatzilla 0.9.67+ [SeaMonkey 1.5a/2005112110]
(Assignee)

Comment 2

12 years ago
Blame's on me for breaking dcc-send. My patch from 0.9.68.5.1 was bad, sorry!
this.prefs = client.prefs needs removing now. It was removed for dcc-chat, though, so as to why that's broken, no clue. Reopening 281172 in a bit.

I'm calling 'charset issue'  on the nickname with ^^ in it. Try using dcc-accept without parameters, or only with 'sid', and it should find the correct nickname by itself. Or just click accept, of course...
Status: UNCONFIRMED → NEW
Depends on: 281172
Ever confirmed: true

Comment 3

12 years ago
I tested with latest trunk ChatZilla. The server I used had casemapping set to ascii, and I used mIRC and X-Chat for "sid^^".

dcc-accept - same as reported. "/dcc-accept sid" worked.
dcc-send - fixed by attachment 204875 [details] [diff] [review].
dcc-chat - mIRC showed "DCC Chat from tH rejected (invalid parameters)". X-Chat showed "* Received a malformed DCC request from tH. * Contents of packet: DCC CHAT chat pLß³[TÝèzðz"
(Reporter)

Comment 4

12 years ago
Next time I'm on, probably tonight, I'll find a volunteer with a letters only nick to test with and let you know what I get.

Comment 5

12 years ago
Ignore what I said about dcc-chat. I tried another ISP and it works fine.
(Assignee)

Comment 6

12 years ago
Created attachment 204916 [details] [diff] [review]
Patch to allow indexOf matching as well as regexp

Okay, here's the problem. the <nickname> and <file> parameters are read as regexps. While that's normally not a problem, as you may know '^' in a regexp means 'match the start of a line'. Obviously, that fails horribly in this case. There's nothing in the help text about this, so I partially blame us. On the other hand, it's hardly not functional - just using /dcc-accept to use the last request would have sufficed (and that *is* in the help).

So, This patch fixes dcc-accept, dcc-close and dcc-decline to also check <nickname> and, where applicable, <file> to also match the literal string you put in, in case it contains regexp characters that you don't want to be interpreted as such. It also adjusts the help texts to note the fact that you can use regular expressions, which is a feature by itself :) .

I'm betting the chat offer not connecting is a problem to do with your firewall and/or router settings. Double-check them; I have not had problems on properly configured machines :). If you have a router, or a firewall that doesn't care about app level when handling incoming requests, set a port (range) and/or list of available port(s) (ranges), and tell the router/firewall to send traffic on that port through.

Other than that, I think all the issues in this bug have been fixed. If, after applying the patch I posted on a current nightly (the dcc-send issue was fixed a few hours ago, see the dependency bug), you still experience problems, please try using the #chatzilla channel on moznet in order for us to debug/troubleshoot the problem with you. Right now the report you made doesn't include info that may be relevant, such as the casemapping of the server you're on, the charset you're using, etc. etc.

Thanks.
Assignee: rginda → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Attachment #204916 - Flags: review?(silver)

Comment 7

12 years ago
Comment on attachment 204916 [details] [diff] [review]
Patch to allow indexOf matching as well as regexp

>Index: mozilla/extensions/irc/js/lib/dcc.js

> CIRCDCC.prototype.getMatches =
> function dcc_getmatches(nickname, filename, types, dirs, states)
> {
>+    function matchNames(name, otherName)
>+    {
>+        return ((name.match(new RegExp(otherName, "i"))) ||
>+                (name.toLowerCase().indexOf(otherName.toLowerCase()) != -1));
>+    }

Nit: semi-colon and blank line here.

>-            if ((!nickname || this.files[k].user.unicodeName.match(n)) &&
>+            if ((!nickname || matchNames(this.files[k].user.unicodeName, n)) &&
>                 (!filename || this.files[k].fileName.match(f)) &&

You didn't change the filename matching per your comment and locale changes.
Attachment #204916 - Flags: review?(silver) → review-
(Assignee)

Comment 8

12 years ago
Created attachment 204919 [details] [diff] [review]
[checked in] Better Patch

New Patch, stuff fixed. Hopefully :).
Attachment #204916 - Attachment is obsolete: true
Attachment #204919 - Flags: review?(silver)

Comment 9

12 years ago
Comment on attachment 204919 [details] [diff] [review]
[checked in] Better Patch

Looks good.

r=silver
Attachment #204919 - Flags: review?(silver) → review+
(Assignee)

Comment 10

12 years ago
Alright, note for checkin: it should be
this.files[k].filename
not
this.files[k].fileName

see the constructor for CIRCDCCFileTransfer. Note that this was broken originally as well :(
(Reporter)

Comment 11

12 years ago
As I side note, I never got an "Accept" pop-up, either. I'm not going to stress it too much at this point. Given my travels tomorrow, I won't be able to download and test until Monday daytime. I'll hit up #chatzilla (is that moznet.edu?) on Monday to test in real time.

Thanks!

Updated

12 years ago
Attachment #204919 - Attachment description: Better Patch → [checked in] Better Patch
Attachment #204919 - Attachment is obsolete: true
(Assignee)

Comment 12

12 years ago
Created attachment 205172 [details] [diff] [review]
[checked in] Patch to s/fileName/filename

Patch to actually do the mentioned change. It wasn't done before applying the patch to cvs.
Attachment #205172 - Flags: review?(silver)

Comment 13

12 years ago
Comment on attachment 205172 [details] [diff] [review]
[checked in] Patch to s/fileName/filename

Yeah, oops! r=silver
Attachment #205172 - Flags: review?(silver) → review+

Updated

12 years ago
Attachment #205172 - Attachment description: Patch to s/fileName/filename → [checked in] Patch to s/fileName/filename
Attachment #205172 - Attachment is obsolete: true
(Assignee)

Updated

12 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED

Updated

12 years ago
Whiteboard: [cz-0.9.69.1]
You need to log in before you can comment on or make changes to this bug.