Bug 123335 - xchat reconnects channels in wrong tabs after network outage.
xchat reconnects channels in wrong tabs after network outage.
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: xchat (Show other bugs)
13
All Linux
medium Severity medium
: ---
: ---
Assigned To: Christopher Aillon
bzcl34nup
:
Depends On:
Blocks: FC7Target F12Target
  Show dependency treegraph
 
Reported: 2004-05-17 06:07 EDT by David Woodhouse
Modified: 2011-06-27 09:53 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-06-27 09:53:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Woodhouse 2004-05-17 06:07:53 EDT
When the network outage such as mentioned in bug #123334 is fixed,
xchat will automatically reconnect to all servers, and to all channels.

However, it does not place each channel in the same tab as it used to
be -- the left-hand tab seems to remain unused and labelled '<none>',
while other channels receive a _different_ channel to the one whose
history they already contain, and a new tab is created for the last
channel connected.

All the channel histories therefore get mixed up over time, because of
this shuffling.
Comment 1 Daniel Reed 2004-08-02 18:40:10 EDT
Is this still the case in the latest xchat package?
Comment 2 David Woodhouse 2004-08-18 06:56:25 EDT
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.
Comment 3 David Woodhouse 2004-08-25 18:34:58 EDT
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.
Comment 4 David Woodhouse 2004-10-05 11:16:43 EDT
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.
Comment 5 Alexandre Oliva 2005-04-18 15:07:51 EDT
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.
Comment 6 Alexandre Oliva 2005-04-18 15:08:11 EDT
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.
Comment 7 David Woodhouse 2005-04-18 19:47:00 EDT
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.
Comment 8 David Woodhouse 2006-03-28 09:41:47 EST
Still happening in FC5.
Comment 9 David Woodhouse 2006-05-30 05:58:45 EDT
Bug is two years old now...
Comment 10 Ray Strode [halfline] 2006-08-13 13:14:10 EDT
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?
Comment 11 David Woodhouse 2006-08-13 14:53:43 EDT
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?
Comment 12 David Woodhouse 2007-05-21 20:53:31 EDT
bug is three years old now.
Comment 13 Kevin Kofler 2007-05-21 21:11:05 EDT
CCing upstream...
Comment 14 Peter Zelezny 2007-05-23 07:11:35 EDT
/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.
Comment 15 David Woodhouse 2007-05-23 07:29:19 EDT
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.
Comment 16 Bug Zapper 2008-04-03 11:34:49 EDT
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.
Comment 17 Alexandre Oliva 2008-04-05 03:13:37 EDT
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.
Comment 18 Bug Zapper 2008-05-13 21:56:17 EDT
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
Comment 20 David Woodhouse 2008-12-07 06:24:16 EST
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.
Comment 21 David Woodhouse 2009-01-19 00:45:11 EST
Still happening in Fedora 10...
Comment 22 David Woodhouse 2009-07-10 05:45:29 EDT
And in Fedora 11... 5 years now...
Comment 23 David Woodhouse 2009-10-10 05:25:28 EDT
And in rawhide which will be F12...
Comment 24 Bug Zapper 2010-03-15 07:49:02 EDT
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
Comment 25 Bug Zapper 2011-06-02 14:45:05 EDT
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
Comment 26 Bug Zapper 2011-06-27 09:53:48 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.