User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/2005012205 In Mozilla 1.7.5, clicking on an irc:// link to join a IRC server would bring up the usual window. The server would send a notice about providing a password: [INFO] Network view for “chat.outboundindex.net” opened. [INFO] Connecting to chat.outboundindex.net via chat.outboundindex.net:6667, attempt 1 of 5... === Please provide your password. (If your client isn't able to, use /quote pass «your-password») At which point I use the /quote pass SOMEWORD to complete the connection. In 1.8b, apon entering the /quote command, chatzilla reports "Not Connected" instead of sending the /quote command and pa.ssword. As a result I can nolonger connect to this particular server using 1.8b. The IRC server is up as connections using mIRC and Mozilla 1.7.5 work fine. Reproducible: Always
13 years ago
Assignee: general → rginda
Component: General → ChatZilla
Product: Mozilla Application Suite → Other Applications
QA Contact: general → samuel
See Bug 270955 for a workaround. Something that will help us is if before you try connecting, go to the client tab and enter "client.HIDE_CODES=false". Then try to connect to the server and tell us what the code is in the left column (where the "===" is now).
[INFO] Network view for “chat.outboundindex.net” opened. [INFO] Attempting to connect to “chat.outboundindex.net”. Use /cancel to abort. [INFO] Connecting to irc://chat.outboundindex.net/ (irc://chat.outboundindex.net/), attempt 1 of 5...  Please provide your password. (If your client isn't able to, use /quote pass «your-password») [ERROR] Not connected.
I tried the workarounds. The first one irc://host/channel?pass=secret works but I don't fancy as it shows the password. The second method irc://host/channel,needpass prompts for the password twice. Frankly I would just prefer to use the /quote command as the prompt in the IRC channel states. Reading Bug 270955, they say this is possible to do and would provide for the backwards compatibility with previous behavious (add to the fact its easier to remember /quote).
Status: UNCONFIRMED → NEW
Depends on: 233831
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
Created attachment 172659 [details] [diff] [review] Add /pass command I also fixed two DCC commands that should require a server (connected network) not just a network.
Assignee: rginda → silver
Status: NEW → ASSIGNED
Attachment #172659 - Flags: review?(samuel)
I'm going to mark this FIXED because we replace the message to say "Please specify your password using the "/pass" command to continue connecting." in bug 233831, and this patch lets /pass work before user registration (unlike /quote and most other commands).
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
The problem is that some server will display a message like "use /quote ..." and so novice users will try that first.
Hmm. Is the message "(If your client isn't able to, use /quote pass «your-password»)" returned by the server or given by the chat client? If it the server, then this bug is not fixed, because novice users will try what they see in front of them.
The point is that the changes made in bug 233831 mean we *don't* show the server message, we show our own one, which clearly says to use /pass. If the user tries /quote pass, they need to read before acting. It is also short/simpler for them. ;)
And if the server doesn't implement /pass, but supports /quote pass ..., the user will never know how to get in and can never issue the command. I do not think the solution sufficient.
Before we adding /pass, the following was sent to the server for each case: /pass foobar -- pass foobar [unknown command, changed into "/quote pass foobar" internally] /quote pass foobar -- pass foobar And after adding /pass: /pass foobar -- pass foobar /quote pass foobar -- pass foobar Let me know if anything breaks because we tell users to use /pass instead of /quote pass.
OK. I'll try it after the nightly rebuild tomorrow and let you know.
OK. Just tried out Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050201 for this and it works fine for me at this time with the server in question.
This fix yet to appear in the Firefox Chatzilla extension too, current 0.9.66 does not have it.
ChatZilla 0.9.66 is not the latest version anyway. The latest release is 0.9.67, and was made *before* this fix. The next version, 0.9.68, will have this fix. There is currently no estimate for the release of 0.9.68 (though I hope that it will be within 6 weeks).
Or if you get a nightly, it will have it.
OK. I have no idea where the nightly builds of Firefox extensions are found though. They do not appear in the Nightly Build section that covers the major programs.
Oh, I missed that part. It will be in the mozilla nightlies. What you could do for firefox is to get a nightly and extract the chatzilla.jar and replace your current one with it.
You need to log in before you can comment on or make changes to this bug.