[Pidgin] #15234: Pidgin IRC protocol: Parting from multiple channels causes corrupted channel parting message

[Pidgin]

#15234: Pidgin IRC protocol: Parting from multiple channels causes corrupted
channel parting message
--------------------+-------------------------------------------------------
 Reporter:  azaq58  |     Owner:  elb   
     Type:  defect  |    Status:  new   
Component:  IRC     |   Version:  2.10.0
 Keywords:          |  
--------------------+-------------------------------------------------------
 This is a bug for Pidgin 2.10.0, yet I did not see much difference in the
 relevant parts of code between this pidgin version and 2.10.6. I'll
 assume, with my interpretation which I will explain below, that the
 problem exists there also.

 This parting message was observed (I choose to censor my username and the
 channelnames in question in an obvious fashion):


 {{{
 6:42 <USERNAME> has left #channel_a ["PART ##channel_b :PART #channel_c
 :PART ##channel_d :PART #channel_e :PART #channel_f :PART #channel_g :PART
 #channel_h :PART ##channel_i :PART ##channel_j :PART #channel_k :PART
 #channel_l :PART ##channel_m :PART #channel_n :PART #channel_o :PART
 #channel_p :PART #channel_q :PART"]
 }}}

 After some research in the source code for the pidgin version in question,
 I discovered that this was not a quit message as it would have been issued
 upon existing pidgin (this would call irc_cmd_quit() in
 libpurple/prototcols/irc/cmds.c), but one generated by a call to the
 function irc_cmd_part() in the same file, which constructs the IRC parting
 commands to be send to the IRC server. I made the following observations:

 1. irc_cmd_quit will always be called on a normal pidgin quit, while
 irc_cmd_part will only be called when a user leaves the channels manually.
 2. A IRC parting command precisely has the structure "PART #channel_name";
 the form of the message suggests strongly that more than one parting
 command were somehow glued together and the remainder terms were
 interpreted as a parting message
 3. The order of the channel names corresponds exactly to the order of the
 channels as it is usually shown in my client.
 4. The function irc_send() in libpurple/protocols/irc/irc.c seems to  have
 some sort of buffering mechanism; messages might not be send directly when
 calling it. I did not look deeply at this, however; therefore, the
 following interpretation might be misguided, but I have not been able to
 come up with anything else.

 This suggests to me the following interpretation:

 I closed all chat windows, which lead to a sudden parting from all
 channels (As I was only made aware of this parting message a few days
 later, I cannot recall how it was generated; hence I had to infer this).
 For each parting, a sudden parting message was issued. irc_send()
 contracted this into one message, with the result that the other parting
 commands were interpreted as a parting message for the first channel to be
 parted from. Hence, besides for the first channel, no other was terminated
 by a parting command.

-- 
Ticket URL: <http://developer.pidgin.im/ticket/15234>
Pidgin <http://pidgin.im>
Pidgin