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.
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:
mIRC should probably only load up the window when it receives 321.
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.
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 --
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.
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).
