Bug 34258 - Pending channel invite prevents you joining the same channel manually
Summary: Pending channel invite prevents you joining the same channel manually
Status: RESOLVED MOVED
Alias: None
Product: Telepathy
Classification: Unclassified
Component: idle (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Telepathy bugs list
QA Contact: Telepathy bugs list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-02-14 07:13 UTC by Ian Molton
Modified: 2019-12-03 20:09 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Proposed fix (2.40 KB, patch)
2011-03-20 02:41 UTC, Debarshi Ray
Details | Splinter Review

Description Ian Molton 2011-02-14 07:13:11 UTC
As summary.

possibly it may block all joins, I didnt try.
Comment 1 Debarshi Ray 2011-03-11 19:14:47 UTC
I am unable to reproduce this. Could you please tell us how to do so? Thanks.
Comment 2 Ian Molton 2011-03-16 11:53:22 UTC
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)
Comment 3 Debarshi Ray 2011-03-20 02:41:31 UTC
Created attachment 44631 [details] [review]
Proposed fix
Comment 4 Will Thompson 2011-04-11 09:32:20 UTC
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.)
Comment 5 Will Thompson 2012-11-14 19:12:38 UTC
http://cgit.collabora.com/git/user/wjt/telepathy-idle/log/?h=34258-invite is the start of a test + revised fix for this.
Comment 6 GitLab Migration User 2019-12-03 20:09:06 UTC
-- 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.