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

New Issue

2026-10-05T04:27:27+02:00

adam commented

2026-10-05 04:27:27 +02:00

(parallel bug has been filed as https://developer.pidgin.im/ticket/11255)

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.

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.

(parallel bug has been filed as https://developer.pidgin.im/ticket/11255) 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. > 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.

adam closed this issue

2026-10-05 04:27:27 +02:00

adam commented

2026-10-05 04:27:28 +02:00

This issue looks to be Pidgin specific - the same set of test parameters in other IRC clients results in no such issue, so it is likely less a ZNC bug and more a client issue.

This issue looks to be Pidgin specific - the same set of test parameters in other IRC clients results in no such issue, so it is likely less a ZNC bug and more a client issue.

adam commented

2026-10-05 04:27:29 +02:00

Well, it seems to me weird ... when the client disconnects abruptly, it cannot be expected that it /PARTs properly, so IMHO ZNC should check when opening new channel that there isn't already one hanging on.

Well, it seems to me weird ... when the client disconnects abruptly, it cannot be expected that it `/PARTs` properly, so IMHO `ZNC` should check when opening new channel that there isn't already one hanging on.

adam commented

2026-10-05 04:27:29 +02:00

I don't think ZNC can be aware of the channels that are open on your client. When you connect to ZNC it sends JOINs for every channel you are joined to. But on a disconnect you are no longer on those channels, so I'd imagine it should be safe to assume you have parted those as you are no longer in them, or you might very well be an entirely different client.

This type of issue also sounds like it can be reproduced without the use of znc, so I'm not entirely sure if I'd classify it as a ZNC issue.

I don't think ZNC can be aware of the channels that are open on your client. When you connect to ZNC it sends JOINs for every channel you are joined to. But on a disconnect you are no longer on those channels, so I'd imagine it should be safe to assume you have parted those as you are no longer in them, or you might very well be an entirely different client. This type of issue also sounds like it can be reproduced without the use of znc, so I'm not entirely sure if I'd classify it as a ZNC issue.

adam commented

2026-10-05 04:27:30 +02:00

@mcepi I'm almost certain ZNC can't be aware of what's open in a client. There's no standard 'API' or way to query the client as to what windows are open, in a way which all IRC clients can provide those kinds of details to the ZNC.

This is not something that can be addressed as part of ZNC, I believe, since there's no way to query the information about what windows are or are not open in the client.

@mcepi I'm almost certain ZNC can't be aware of what's open in a client. There's no standard 'API' or way to query the client as to what windows are open, in a way which all IRC clients can provide those kinds of details to the ZNC. This is not something that can be addressed as part of ZNC, I believe, since there's no way to query the information about what windows are or are not open in the client.

adam commented

2026-10-05 04:27:31 +02:00

Pidgin is NOT a real IRC client.

Pidgin is NOT a real IRC client.

adam commented

2026-10-05 04:27:31 +02:00

Echo what @KindOne- said. Pidgin is not a real IRC client, either, and shouldn't be treated as one.

Echo what @KindOne- said. Pidgin is not a real IRC client, either, and shouldn't be treated as one.

adam commented

2026-10-05 04:27:32 +02:00

From http://paste.fedoraproject.org/227922/24457143/

[07:48] <yitz_> I would blame Pidgin on handling multiple JOINs poorly. I would blame ZNC for sending multiple JOINs without a PART.
[07:48] <yitz_> Two unrelated issues

Why do we have http://wiki.znc.in/Disconkick as a loadable module instead of it being in core and always on?

From http://paste.fedoraproject.org/227922/24457143/ > [07:48] <yitz_> I would blame Pidgin on handling multiple JOINs poorly. I would blame ZNC for sending multiple JOINs without a PART. > [07:48] <yitz_> Two unrelated issues Why do we have http://wiki.znc.in/Disconkick as a loadable module instead of it being in core and always on?

adam commented

2026-10-05 04:27:33 +02:00

Why do we have http://wiki.znc.in/Disconkick as a loadable module instead it being in core and always on?

👍 that module is must-load and I have it always loaded, losing connection is too confusing otherwise.

> Why do we have http://wiki.znc.in/Disconkick as a loadable module instead it being in core and always on? :+1: that module is must-load and I have it always loaded, losing connection is too confusing otherwise.

adam commented

2026-10-05 04:27:33 +02:00

that module is must-load and I have it always loaded, losing connection is too confusing otherwise.

Do I miss something? When reading http://wiki.znc.in/Disconkick it seems to me that this works when ZNC is discontinued from the IRC not the other side of ZNC between the bouncer and the client, doesn’t it?

> that module is must-load and I have it always loaded, losing connection is too confusing otherwise. Do I miss something? When reading http://wiki.znc.in/Disconkick it seems to me that this works when ZNC is discontinued from the IRC not the other side of ZNC between the bouncer and the client, doesn’t it?

adam commented

2026-10-05 04:27:34 +02:00

Of course, when ZNC is disconnected from IRC server.
Your issue happens when what disconnects from what?

Of course, when ZNC is disconnected from IRC server. Your issue happens when what disconnects from what?

adam commented

2026-10-05 04:27:35 +02:00

@DarthGandalf his issue is when the link with a // in it below is flapping or disconnects briefly, from what I can tell as discussed above:

IRC Client <--//--> ZNC <------> IRC Server

The referenced Pidgin bug states that when IRC <----> ZNC is reestablished, Pidgin shows duplicate tabs for the channels and such.

@DarthGandalf his issue is when the link with a `//` in it below is flapping or disconnects briefly, from what I can tell as discussed above: ``` IRC Client <--//--> ZNC <------> IRC Server ``` The referenced Pidgin bug states that when `IRC <----> ZNC` is reestablished, Pidgin shows duplicate tabs for the channels and such.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/znc#525