[Bug 34258] Pending channel invite prevents you joining the same channel manually

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Mon Apr 11 18:32:27 CEST 2011


https://bugs.freedesktop.org/show_bug.cgi?id=34258

--- Comment #4 from Will Thompson <will.thompson at collabora.co.uk> 2011-04-11 09:32:20 PDT ---
Review of attachment 44631:
 --> (https://bugs.freedesktop.org/review?bug=34258&attachment=44631)

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

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.



More information about the telepathy-bugs mailing list