As summary. possibly it may block all joins, I didnt try.
I am unable to reproduce this. Could you please tell us how to do so? Thanks.
Set up two machines, with two people. label them A and B. Run Empathy on B Have A create a new channel and send an invite to B Have B join the channel by name (NOT by responding to the request). This will fail reliably here. (in the process of confirming this bug, I noticed that you cannot re-invite someone to a channel if they accidentally decline the first request, too)
Created attachment 44631 [details] [review] Proposed fix
Review of attachment 44631 [details] [review]: This is the kind of thing for which a short regression test would be really good; both testing Ian's original case, and the case I'll describe below. I can't see any way how the channel's state will change to MUC_STATE_JOINING when the join request is sent. So consider the following sequence of events: 1. A contact invites me to #foo. 2. I call EnsureChannel(... #foo ...). 3. Idle sends JOIN #foo to the server. 4. Before the server replies, I decline the invitation. This causes part_from_channel() to be called (by remove_member()); with that patch, that function checks priv->state, finds that the state is CREATED (which is not >= JOINING), and so doesn't bother to send PART; the channel closes. 5. Now the server replies to our JOIN, and we're in the channel, but we didn't want to be. This seems like a bug. ::: src/idle-muc-channel.c @@ +1754,3 @@ } + idle_muc_channel_part(obj, priv->connection->parent.self_handle, msg); Calling this function even if we're waiting for a reply to our PART request is wrong: it means the channel is signalled as closed at the Telepathy level immediately, rather than when the server acknowledges that we've left the channel. (This is related to my overall point.)
http://cgit.collabora.com/git/user/wjt/telepathy-idle/log/?h=34258-invite is the start of a test + revised fix for this.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-idle/issues/25.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.