Forums Bug Reports Assuming PART is always successful

mIRC assumes the PART command is always successful, which is not the proper way to handle PART messages.

mIRC should wait until the PART is received from the server after "PART #channel" is sent. This would be the proper way to handle parts, as PART is a command that returns a success message.

I can't reproduce this issue here, if I join a #channel and then /part #channel, the channel window is closed only when the PART event from the server is received. Can you describe a step by step process that reproduces the issue you are seeing?

Yes, mIRC waits for the PART from the server when /part is used, but not when the window is closed using the close button.

Are you suggesting that when the user closes a channel window, the window should not actually close until it receives the part event from the server?

This is weird..

/part #channel

-> irc.StormIRC.org PART #channel
<- :Andy!Madison@NetAdmin.StormIRC.org PART #channel

Clicking on the close button

<- :Andy!Madison@NetAdmin.StormIRC.org PART #channel
-> irc.StormIRC.org PART #channel
<- :Andy!Madison@NetAdmin.StormIRC.org PART #channel

I don't actually understand all this at all, shouldn't both cases be the same or?

Not really. Clicking the X button is a UI interaction saying you want the window closed. In my opinion that means mIRC should close it ASAP. It's basic useability that the UI should be as responsive as possible. User presses X - window closes. No delays. No "but only if the server agrees". Just close it.

Apparently when you close a channel window, mirc fakes the receipt of a PART message from the server and then sends a PART command to it. From the scripter's point of view, this allows the usage of the on PART event as a form of on CLOSE event for the channel window. The main use of that is presumably the ability to do something like this:
ie to be able to specify a default part message (either global or per-channel/network), sort of like you can specify a default quit message in Options. This way mirc sends two part messages, first the one you specified in the on PART event and then the internal one (which mirc sends anyway). The second PART command results in a "No such channel" response from the server, but mirc hides that message, so the user doesn't notice anything.

I agree that it should not wait for the server to respond. It should first close the window, ignore any server messages pertaining to the parted channel, and then send the part command. I've always assumed this is how it worked.

Originally Posted By: qwerty

The second PART command results in a "No such channel"

Why would that happen when the first is faked? Technically the client would still be on the channel. So, when the window is closed, mIRC would fake the incoming part message triggering the part event, and then issue the part command to the server provided a script has not already done so.

Not sure I'm reading that correctly, but what I said before is that a PART reply is faked (incoming PART message), not a part command (outgoing).

Apparently mirc doesn't check that. If you're asking why not, I can't answer that, but the fact that Khaled chose to hide the "No such channel" message instead of checking whether a script sent a PART command before the internal one probably means that implementing the former was easier.

Edit: as it turns out, mirc doesn't even hide the "No such channel" (or "You're not on that channel") message (thanks Sat)... so implementing nothing is definitely easier :P

I guess what I meant was, why would mirc issue a fake part command. But maybe it would do that for the same reason it would fake an incoming part message from the server. Issue a fake part command so that if there is a scripted part alias, it is used, and fakes an incoming part message so the part event is triggered. I think I have myself confused now.

mIRC doesn't issue a fake part command. It issues a real one after it has faked a part receipt and already closed the channel window.

Yeah that's how I described what I thought happened when I said...

Originally Posted By: RoCk

when the window is closed, mIRC would fake the incoming part message triggering the part event, and then issue the part command to the server provided a script has not already done so.

2 cents from the UnrealIRCd team:

2 cents is about all their IRCd is worth, but they made good points too.

Also note to them that it was users of that "POS client" that were making the comments and giving the opinions, not the creator or the client.

If that's all it was worth, then why do the majority of the servers polled on Search IRC show to be using a version of UnrealIRCd.

In my opinion, the number of servers using Unreal contradicts your statement of it only being worth about 2 cents.

Thanks for the comments, this is just my personal preference... implementing it the other way is easier (and I did try it out many years ago) but I felt more comfortable with the current behaviour. Is there some reason why you would prefer it to behave differently? Is it important?

To put your statistic in perspective: according to the same site, of all 4233 networks, the top 12 combined carry roughly two thirds (66.5%) of the total IRC userbase. None of those networks are using unrealircd.

So, perhaps it's because every idiot and their dog can set up one? Or because its bells and whistles, and in particular its habit of taking away freedom from the user and giving it to IRCops (need I even mention SAJOIN?) are attractive for power hungry kids? I don't know, but none of that automatically means it's not a POS ircd.

Back on topic though.. what could possibly make PART fail anyway?

You'll also note however that none of the top networks use it, including DALnet, Quakenet, IRCnet, EFnet, Undernet, GameSurge, UniBG, Rizon or freenode. Such networks account for around 600,000 users, which is well over 50% of the IRC population as a whole.

I'm not passing judgment here, but its general reputation is that it's used by newbies who are more interested in having lots of IRCop powers, silly amounts of channel levels that extend beyond the basic op/voice/halfop and have little or no experience running a server but want to do it anyway. Despite this however, a few of their developers seem to find it enjoyable being rude/arrogant and so it's not a surprise if their opinion isn't greeted with open arms *shrugs*

As for the "bug report", this is absolutely pointless. The Microsoft comparison doesn't really work, because whilst there are plenty of apps which will ask for confirmation before closing, there are plenty that don't. The decision is based on an individual basis (so Word/Notepad/etc quite obviously should ask for confirmation, IE probably shouldn't). In mIRC's case (in my opinion) the behaviour at the moment is quite correct.

Stealth, your opinion is welcomed, please do not relay further messages from the "unrealircd team" if they can't be bothered to register.

Regards,

It was my opinion, that's all.