Opened 9 years ago

Last modified 4 years ago

#11255 new defect

Pidgin opens identical second tab if server sends JOIN without PART first.

Reported by: CShadowRun Owned by: elb
Milestone: Component: IRC
Version: 2.6.4 Keywords:
Cc: mcepl, teward

Description

If the server sends JOIN twice, you end up with 2 channels tabs, on the same network, with the same name.

Example: I am using the ZNC bouncer, sitting on #test. ZNC gets disconnected from the IRC network. ZNC reconnects to the IRC network. ZNC re-joins #test. Pidgin shows 2 tabs for #test, both look identical. I've attached a raw log of this.

Expected behaviour: Pidgin should not open another tab, and instead use the existing tab.

Attachments (3)

rawlog.txt (6.2 KB) - added by CShadowRun 9 years ago.
Log of ZNC sending JOIN without sending part first, causing duplicate tabs.
cdf59ccc4d37c43e737c89d84c412cf4e5b3beba.patch (978 bytes) - added by mcepl 4 years ago.
suggested patch
fix11255-no-two-JOINs.patch (1023 bytes) - added by mcepl 4 years ago.
suggested patch for python 2.6 / 2.7 issue

Download all attachments as: .zip

Change History (10)

Changed 9 years ago by CShadowRun

Log of ZNC sending JOIN without sending part first, causing duplicate tabs.

comment:1 Changed 9 years ago by elb

You are probably correct that this is a libpurple IRC bug. However, it is *certainly* a ZNC bug. I suggest you get your bouncer fixed, as well.

De-duplicating JOIN messages in Pidgin should not be terribly difficult, although I suspect you will find that there are other buglets -- e.g., if the names list for the room changed while you were gone, your user list may be stale. The server does send a NAMES list for the second join, but we do not treat spurious NAMES responses at canonical. Whether we should or not in this case is unclear, since there is obviously a server bug. Dumping the current user list in the trust that a NAMES will be forthcoming is bogus, so that asks for more state. More state to work around a bouncer bug seems like a poor trade off.

comment:2 Changed 4 years ago by mcepl

Just to note that I can happily reproduce this issue with pidgin-2.10.7-24.el7 against znc-1.4-1.el6.x86_64.

comment:3 Changed 4 years ago by teward

In rebuttal to mcepi who commented on the issue on ZNC (see https://github.com/znc/znc/issues/968 for that issue), the issue is less a bouncer problem and a failure of implementation in Pidgin to detect that an IRC window already exists.

If the issue were a bouncer specific problem, we would see this in other clients such as XChat, HexChat, mIRC, and others. As all the big IRC clients do not have a similar problem, it stands to reason that this is an issue specific to Pidgin and/or libpurple.

As well, additional comments on the issue as listed on ZNC have alluded that it would be necessary for ZNC to see that the window already exists. There is no such way to sanely apply such 'API queries' for every client to expose that the window already exists. There is also no IRC spec for that, as well, which suggests even moreso that this is a Pidgin implementation problem, and not a bug in ZNC.

Five years ago we would see the same problem - this is still a case of implementation failure in Pidgin, and nothing that can truly be fixed in ZNC.

comment:4 Changed 4 years ago by mcepl

I have here opinion (from #irssi channel on FreeNode) http://paste.fedoraproject.org/227922/24457143/ that BOTH pidgin and znc have a bug. Just noticing it, without any further comment ATM.

Version 0, edited 4 years ago by mcepl (next)

Changed 4 years ago by mcepl

suggested patch

comment:5 Changed 4 years ago by mcepl

Wandering whether this (see https://gitlab.com/mcepl/pidgin/blob/11255_multiple_tabs_reconnect/libpurple/server.c) could be the solution for this problem? Could it be that simple?

comment:6 Changed 4 years ago by elb

This is absolutely a bouncer bug. Any claim that it is not is ludicrous.

Pidgin could handle it better, though -- most IRC clients do. The fact is that IRC is both poorly specified and poorly implemented in most cases. When workarounds do not break correct behavior or require substantial logic (which could contain bugs), applying them is reasonable.

This patch from mcepl appears correct to me. We should apply it.

Changed 4 years ago by mcepl

suggested patch for python 2.6 / 2.7 issue

comment:7 Changed 4 years ago by mcepl

Unfortunately, I don't have a good results with this: somehow the chatrooms are not fully updated (see https://mcepl.fedorapeople.org/tmp/Screenshot%20from%202015-06-10%2017-55-55.png) — although I can send commands to the IRC server (e.g., /whatis) and I get proper results, I cannot write to the channels (after writing the text to the textbox, ENTER doesn't have any effect).

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!