Bug 28918

tp_channel_manager_emit_new_channel is fired twice:

- In _join_handler() when we receive the JOIN command from bip
- In _channel_join_ready_cb()  when we actually joined the room

I guess we shouldn't emit the first NewChannels signal but I don't know enough of Idle/IRC to be sure that's the proprer fix.

The same thing happens when you get invited to a channel that you are not already a part of.

Basically whenever a JOIN message is received for a channel that you did not attempt to join yourself.

(In reply to comment #2)

> Basically whenever a JOIN message is received for a channel that you did not
> attempt to join yourself.

Oops, sorry! What was I thinking? Here is the correct analysis.

Whenever we try to handle an INVITE or a JOIN for which there is no channel, we do (as Guillaume wrote):
+ _muc_manager_new_channel
+ tp_channel_manager_emit_new_channel (emits NewChannels)

After that, in case of JOIN, irrespective of whether there was a channel or not, we do:
+ idle_muc_channel_join (emits NewChannels)

And in case of INVITE, we try a normal join operation if the user wants to, which leads to a NewChannels as well.

I am not sure about the behaviour in case of an INVITE, but for the _join_handler, the easy way out is to not call tp_channel_manager_emit_new_channel.

However, I am told that older versions of Bitlbee (http://www.bitlbee.org/main.php/news.r.html) does not want the client to leave the &bitlbee channel and sends a JOIN to the client whenever it does so. I don't know if this is a correct use of JOIN and since newer Bitlbee versions don't do so, I am not sure if we should support this.

Created attachment 45793 [details] [review]
Do not emit an extra NewChannels while handling a JOIN message

Created attachment 45949 [details] [review]
0002 Test to cover MUC JOIN initiated by the server

Created attachment 45950 [details] [review]
0003 Strengthen the MUC JOIN test to forbid duplicate NewChannels

Although not directly related to this, it might be a good idea to improve the existing channels/join-muc-channel.py to forbid duplicate NewChannels.

Review of attachment 45950 [details] [review]:

Looks good.

Review of attachment 45949 [details] [review]:

Could the test also check that PARTing a room, and having the server echo the PART followed immediately by JOINing you again, works?

::: tests/twisted/channels/join-muc-channel-bouncer.py
@@ +3,3 @@
+Test connecting to a IRC channel
+"""
+

I think this comment needs updating to match the test! :)

Review of attachment 45793 [details] [review]:

If all the tests pass, including your new one, then this looks fine!

Created attachment 46264 [details] [review]
Handle PART messages in our test IRC server

(In reply to comment #8)
> Review of attachment 45949 [details] [review]:
> 
> Could the test also check that PARTing a room, and having the server echo the
> PART followed immediately by JOINing you again, works?

Done.

> ::: tests/twisted/channels/join-muc-channel-bouncer.py
> @@ +3,3 @@
> +Test connecting to a IRC channel
> +"""
> +
> 
> I think this comment needs updating to match the test! :)

Done.

Created attachment 46265 [details] [review]
0002 Test to cover MUC JOIN initiated by the server

Committed and pushed.