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.
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.
