Forums Bug Reports /LIST window can appear upon /QUIT (mIRC 7.17)

I encountered a server today which responded to /LIST thusly...

-> irc.server.com LIST
<- :irc.server.com 481 yournick :Permission Denied: Insufficient privileges

mIRC did not realize that 481 was the server's official response to the /LIST command, and continued to await 321/322/323 channel listings data from the server forever (as evidenced by my re-typing /LIST producing only "* /list: listing in progress...").

I presume that's not a mIRC bug, because I believe 481 isn't a LIST-specific server response (i.e., mIRC has no way of knowing that 481, in such a case, is the server's response to /LIST).

However: I also noticed that upon later disconnecting from that server with /QUIT, mIRC's channel listing window suddenly appeared "out of nowhere", showing 0 channels.

After a little more experimentation (including verifying this also happens with the /DISCONNECT command), I felt that this behavior might count as a bug. Specifically: once mIRC's internal 321/322/323 event "listener" is started by /LIST, it appears that mIRC forgets to cancel/abort it if /QUIT or /DISCONNECT happen before 321 arrives.

(Which means this bug would also affect people who run /LIST on a server that has become non-responsive and who then /QUIT or /DISCONNECT -- not just people using a server that responds 481 to /LIST. )

i'm really not crazy about how mIRC handles /list; how we're not able to control the list window, how $line() is inaccurate with it, etc. it's not a great solution, since /list performs a little handling before sending a request to the server, but you can use /raw list <parms> to send a request directly to the server and override the mechanism that prepares mIRC for receiving the list of channels. that way, if the server sends back an unrecognized response, nothing will have changed internally :P

Did mIRC return 0 channels immediately after quitting? Or some random time after?

The /list window opened with 0 channels listed in it immediately upon hitting enter after typing /QUIT or /DISCONNECT. (It literally "felt" like /QUIT itself was invoking the channel list window each time it happened to me -- until I realized what was truly going on.)

Since my first post, I figured out how to reproduce the problem. The server I encountered was running Beware IRCd -- an Undernet IRCu clone for Windows 9x/NT/XP and Linux. Turns out it's very easy to download and configure it such that this mIRC bug can be reproduced:

1. Unpack http://ircd.bircd.org/bewareircd-win32.zip to a temp folder (there is no OS installation process).
2. Open bircd.ini in text editor, scroll all the way to the bottom, find "OperOnlyCmds=", change it to "OperOnlyCmds=LIST", re-save bircd.ini. (This is what will cause the IRCd to send a 481 response in reply to /LIST in mIRC.)
3. Execute bircd.exe with no commandline parameters.
4. In mIRC, /server 127.0.0.1 6667
5. Once connected, type /LIST
6. [do anything here with the server that you wish, for any period of time you wish]
7. /QUIT, and mIRC's channel list window will immediately open.
8. Execute "bircd signal stop", then delete temp folder you unpacked Beware IRCD into.


The design of mIRC's channel listing window seems to be an homage to mIRC's earliest years, yeah. The main way I'd love to see it modernized is the addition of re-sizable column headers that are also clickable for changing sort order. (Re-sizability being the really important part, considering that many IRC networks allow channel names long enough these days to be truncated in mIRC's list)


Good thought.

So I'm confused. Why is this a bug? What would you expect mIRC to do here?

I think it's reasonable for a disconnect event to cancel a /LIST request, and, therefore, show what mIRC has retrieved. I don't see this as "out of nowhere", since you told mIRC to get you a LIST, and mIRC got it (or was in the middle of getting it, for all intents and purposes).

The real problem here is that the IRCd is returning an invalid response, causing mIRC to wait indefinitely for a *real* response. It *should* wait indefinitely for a real response. Quitting *should* cancel this request and display what mIRC has retrieved.

I think that it would be reasonable for mIRC to eventually give up (after a few minutes) if it never receives any valid response to the /LIST request, and in that case, not create the channel list window at all.

Showing the list after disconnecting is silly, especially if there are zero channels found. It should just say something like: "* /list: channel list cancelled due to user disconnect." or something.

My thought is rather simple on this one:

My understanding is that mIRC is not supposed to open its channel listing window unless the server sends a 321 (signaling the start of channel listings).

So my thinking is that if no 321 ever arrives from the server after typing /LIST, the channel list window should not open -- upon typing /QUIT, /DISCONNECT, or otherwise.

Remember, this issue won't just occur with broken servers. It will occur with any server that becomes permanently non-responsive prior to the user typing /LIST, and as soon as that user gives up and disconnects. Because it is the act of disconnecting after typing /LIST but before the server sends a 321 that causes the issue.

@hixxy - A message like that would be more appropriate, yeah.

Actually, showing the list after disconnecting is arguably silly *ONLY* if there are zero channels. You *WANT* to show the channel list if you get disconnected in the middle of a list, specifically because you don't want to lose the data you had before you got disconnected.

Realize that cancelling a /list does not equal throwing away all the data you received up until the cancellation. Users might quit *because* a list is taking too long, in order to stop listing and use what they already have. Servers might also disconnect you in the middle of a LIST because your SENDQ exceeds a certain limit-- which may or may not happen after data has been sent. Both of these scenarios have data to display in the list window.

The only possibility is that zero channels display *and* you quit. Again, it's arguable whether this is "silly". The absence of data is in itself useful data. Personally, if no channels display during a list, and I disconnect, I'd still want to see that for myself. The message "* /list: channel list cancelled due to user disconnect." makes it ambiguous whether or not there was data to view. "* /list: disconnected before receiving any data" might be better, but you could just as easily illustrate that by showing the empty window. They are effectively equivalent behaviours. I see nothing "silly" about that.

That's a fair point. mIRC should probably only load up the window when it receives 321.

That's the bug IMO, not that it shows the window on disconnection.

I guess we could also discuss whether mIRC should activate the list window when it "finishes" (I can't confirm, is that what it's doing?). It should probably highlight the switchbar/taskbar, but not activate the window when a list completes. Activating the window [if that's what it does] seems way too obtrusive, even if you're still connected when it happens.

Fair point, although I can't really think of many uses for the channel list window when you're no longer online.

Opening the list window when no channels are found can only be described as an annoyance. In this scenario, whether the user disconnected or not, a * /list: no channels found message would be much better imo.

Except that mIRC doesn't know how many channels are found until the end of list response is returned. It opens the window upon issuing a LIST and waits for the channel responses. That's not annoying at all. You're evaluating this feature in the wrong context. If you look at it as: "mIRC pops up a window that it doesn't use", yes-- that's annoying. But that's not how the feature works. The window is used as a placeholder for channel information in real-time as they come in from the server. If zero channels come in, that sucks-- but mIRC doesn't know that no channels came in until it's over-- ie. after it opened the window to watch for those channels.

As far as uses for a channel list when disconnected go-- by your logic, there's no use for a channel window when you're no longer online. mIRC should force those to close too. .. but seriously, I provided two scenarios where you would disconnect and still want the /LIST results in my last post. You don't need to think at all, they're right there. Channels live beyond your IRC connection, disconnecting from a server doesn't mean you will never use IRC again. Channel information from a /LIST will still be useful. That is why mIRC can save /LIST output to text files. Go figure.

It actually sounds to me like you don't use /LIST, or haven't in a really long time. I don't think it's fair for you to comment on the supposed annoyance of a feature that you don't even use.

Agreed.



The window activates when it is created, but mIRC will not activate it again when the LIST completes. Instead mIRC makes a "ding" sound when the list is completed, and the channels list is highlighted with red text in the switchbar/treebar at the same time (if it's not currently the activate window). All this seems like good behavior to me.

The opposite, actually.

In fact everyone here seems to be getting the wrong impression of all this. In truth, mIRC already does open up the /list window only if it receives a 321. So that aspect isn't broken. What I believe to be a bug is the fact that mIRC also opens up the /list window if you disconnect and it hasn't yet received a 321.

Let me try to explain the bug this way.....

mIRC already behaves in all the following ways (which I agree with):

* If you type /list, and then if the server sends 321 followed immediately by 323 (indicating 0 channels), then yes, the /list window should open showing 0 channels.

and

* If you type /list, and then if the server sends 321, and then if you disconnect before any 322s (channel listings) can arrive, then yes, the /list window should open showing 0 channels.

and

* If you type /list, and then if the server sends 321, and then if the server starts sending 322s, and if you then disconnect before 323 arrives, then yes, the /list window should open and show the partial channel list you did get before you disconnected.

Again, mIRC already does everything above, and I cocnsider all three above examples correct and desirable behavior.

Yet what mIRC also does (what I'm calling a bug) is:

* If you type /list, and if the server never sends a 321, then the /list window opens up showing 0 channels when you disconnect

That's bad. The reason it's bad is because it gives you the impression the server has 0 channels, when in fact, the server never even got as far as telling you what channels were available, including the possibility of 0 channels.

So I think that if someone types /list, and if the connection is dropped/lost before the server's 321 arrives, then what mIRC ought to do is NOT open the /list window, and instead print a status window message like "* /list: server connection terminated before any channel listings data could be received".

P.S. Servers only send 322s (channel listings) and 323 ("end of channel list") after a 321. So yes, this means that mIRC can treat the fact that 321 hasn't yet arrived when a disconnection occurs as proof that not only were no channel listings received, but that even confirmation of 0 channels wasn't received. Hence making it logical for mIRC to not to open the /list window in this case, and to instead just display a status window error.

Okay. The behaviour is more clear now, I think. Yes, that is a bug. If 321 was not sent, no other event should cause the channels window to open (disconnect included). This is an extension of what I said earlier, though:



As you pointed out (which I was not aware of), mIRC already does this-- EXCEPT when you disconnect prior to 321 being sent. So the implementation is missing this exception case.

The reason for that is that some networks do not send a 321, they go straight to sending 322, if any, and finally a 323.

It can be tricky handling numerics with different behaviours across networks. mIRC attempts to work in a way that is as intuitive and compatible as possible across all of them.

I have added support for numeric 481 so that if mIRC receives it, it will cancel a channels /list request. If anyone is aware of numeric 481 being used for a different purpose on another network please do let me know.

From the "standard" set of RAW numerics located on mIRC.net

Why would they not allow /list ?

In deed. Though now thanks to Khaled's clarification, it seems either 321 or 322 will cause the /list window to open. Still, the nature of the bug remains unchanged.

That said, Khaled --



Well, that would solve the issue when it came to servers which awkwardly send 481 in response to /list. But the bug would still persist for users who send /list to servers that have become unresponsive. (I.e., the /list window would still pop open when the user eventually /quits despite the server having sent neither 321 nor at least one 322.)

Maybe it would work better if mIRC cancels the list "anticipator" if (disconnection) && (!321_seen) && (!322_seen)? Or in other words, if (disconnection) && (list_window_not_already_open).

Following this logic, perhaps mIRC should only do the following:

1. If 321 is received, open the window
2. If 322 is received, check for the window, open if it is not opened.

Those should be the only cases that cause the window to open.

If a disconnect occurs and the window isn't open yet-- it shouldn't be opened by the event. In other words, disconnection should never open the window for any reason whatsoever. Only the raws 321 and 322 should perform a CreateWindow. I'm not even sure why mIRC creates a window on disconnect anyway.

I think that would solve the discrepancy.