[Pidgin] #8385: XMPP rejoining chats interacts oddly with new caps code

[Pidgin]

#8385: XMPP rejoining chats interacts oddly with new caps code
------------------------+---------------------------------------------------
 Reporter:  darkrain42  |           Owner:  darkrain42
     Type:  defect      |          Status:  new       
Component:  XMPP        |         Version:            
 Keywords:              |   Launchpad_bug:            
------------------------+---------------------------------------------------
 The new capabilities code (soc.2009.xmpp and cpw.darkrain42.xmpp.bosh)
 interacts poorly with rejoining a MUC that is already open because the
 initial presence is sent with a caps hash that immediately changes after
 we disco#info our server.

 The rejoining is triggered in gtkconv.c by a connection signed-on signal
 in gtkconv.c and occurs before disco#info (or initial presence or roster,
 etc).

 Once we've disco#info'd the server, my caps hash immediately changes to a
 new node (since my server supports PEP, I believe). In the mean time, room
 members see the hash from the initial presence and send my client an IQ
 get for it; pidgin replies with an error because (by that point) that is
 no longer our own caps hash.

 This ticket is mostly a reminder to myself that it'd be nice to figure out
 a way to fix this interaction, ideally by not sending the chat join until
 after we send our normal initial presence. One way to do that would be to
 wait to tell the core we're connected until we've received the roster/sent
 initial presence.

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