Bug 123335

Is this still the case in the latest xchat package?

I've seen it recently, but possibly not in 2.0.10 yet. Will try to
reproduce. Certainly I've seen it since 2.0.6 when it was supposed to
have been fixed.

It just happened in xchat-2.0.7-6. While connected to a server which
was disconnected from the rest of freenode, I did /server
irc.ipv6.freenode.net to change servers, then had to rejoin all
channels -- and they came back in the wrong tabs.

Just happened again in xchat-2.4.0-3

Changed servers with /server
Waited for it to reconnect to the channels
Decided it probably wasn't going to
Typed /join ...
Watched it bring a bunch of them back in the wrong tabs.
I was on 6 channels, with six tabs.

The first tab is now disconnected. The old channel name is in parentheses.
Then there's a new tab with no history, connected to what _was_ the
second channel.
Then there's what was the first channel, in the tab which previously
held the second channel.
The third and subsequent channels seem to have got reattached this
time -- it's not all off-by-one as I believe I remember it being before.

This seems to be better now, but there's still one annoying bug:

if I don't have a separate tab for the server, on reconnect, the `active
channel' for that server doesn't get reconnected.  (by active channel I mean the
channel on which the reconnect attempt messages are displayed, even if the
currently-active tab is a different one, from a different server)

if I do have a separate tab for the server, on reconnect, the name of that tab
often changes to the name of a server I'm not even connected to.

This is all with xchat 2.4.3 on x86_64.

This seems to be better now, but there's still one annoying bug:

if I don't have a separate tab for the server, on reconnect, the `active
channel' for that server doesn't get reconnected.  (by active channel I mean the
channel on which the reconnect attempt messages are displayed, even if the
currently-active tab is a different one, from a different server)

if I do have a separate tab for the server, on reconnect, the name of that tab
often changes to the name of a server I'm not even connected to.

This is all with xchat 2.4.3 on x86_64.

This isn't fixed. It's still happening for me with xchat 2.4.3 on ppc.

After /quit and subsequent /reconnect, I still see channels reconnected in the
wrong tabs. What was six channels: #1,#2,#3,#4,#5,#6 is now seven tabs:
(#1),#1,#3,#4,#5,#6,#2

The first tab is dead, the first channel has usurped the second tab, and the
second channel has moved to a new tab. The rest are back in the right place.

Still happening in FC5.

Bug is two years old now...

maybe this is somehow a ppc specific problem.  Otherwise, I wonder why the CC
list isn't longer...

Does running it through valgrind present any useful spew?

It was first reported on i386. I haven't tried valgrind -- why do you think that
would be relevant? That is; what should I be looking for?

bug is three years old now.

CCing upstream...

/RECONNECT alone seems to work, rejoins all the channels and in the correct tabs
(can you confirm that too?). Testing 2.8.2 of course.

I guess the whole problem is that after a /QUIT it won't send the JOIN line to
the IRC server anymore. This could be made to work for /reconnect.

For me it _usually_ comes back in the right places. But not always. In the three
years I've been seeing this, I haven't really established a pattern. Perhaps
it's more likely to happen when a reconnect attempt has _failed_ -- it happens
more when there's a real network outage, but just suspending my laptop and
moving from place to place, then issuing '/allserv reconnect' generally seems OK.

Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

Still happening in F8, for sure.  Maybe on rawhide as well, although this
problem doesn't get my attention any more to the point that I can tell for sure.

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Still happening in Fedora 10. Bug is 4½ years old now...

It doesn't happen on _every_ reconnect, but often enough that it's extremely annoying.

Still happening in Fedora 10...

And in Fedora 11... 5 years now...

And in rawhide which will be F12...

This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle.
Changing version to '13'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.