Bug 274862

Summary:	Moving tabs then closing them results in wrong tab labels
Product:	[Applications] konqueror	Reporter:	Brendon Higgins <brendon>
Component:	tabbing	Assignee:	Konqueror Developers <konq-bugs>
Status:	RESOLVED FIXED
Severity:	normal	CC:	frank78ac, kde_bugs
Priority:	NOR
Version:	4.6.3
Target Milestone:	---
Platform:	Debian unstable
OS:	Linux
Latest Commit:		Version Fixed In:	4.7.4
Sentry Crash Report:

Description Brendon Higgins 2011-06-03 20:35:12 UTC

Version:           4.6.3 (using KDE 4.6.3) 
OS:                Linux

The labels on tabs get screwed up if you move tabs around and then close some. It seems to need some particular number of tabs or a particular way in which they are moved/closed to demonstrate, and I haven't figured out the general pattern. But see Steps to Reproduce for an example that always does it.

Reproducible: Always

Steps to Reproduce:
1. Open a window with five tabs - e.g. go to Slashdot and open the first four stories in a new tab each.
2. Click on the rightmost tab, and drag it two slots to the left so that it becomes the middle tab.
3. Close the tab that is now the rightmost tab. You can click the "X" directly or select the tab, then close it.

Actual Results:  
The tabs are renamed such that the tab you *moved* seems to disappear. However, the actual contents of each tab are as you would expect; the labels in the tabs starting with the one that you moved and those to the right of it become wrong.

Expected Results:  
The correct tab label disappears, and the remaining labels correspond to their contents.

Things only get worse if you use the undo closed tab function (two tabs with the same label).

Comment 1 Frank Reininghaus 2011-06-09 16:15:53 UTC

Thanks for the bug report! I can confirm the issue in master.

Comment 2 Brendon Higgins 2011-08-01 19:13:16 UTC

Something I just noticed, almost certainly related to this bug: If you move tabs around, further browsing can induce status colouration on the wrong tab. What I mean is the following. Normally, a background tab has its title drawn in orange colour while the page is being loaded, and blue when the page is ready. This then turns to black once the tab has been viewed. But if you move tabs around in Konqueror, you can have it so that browsing in one tab invokes this behaviour for a different tab.

It all indicates that there is something quite wrong with the way tabs are referenced (at least in versions up to 4.6 - don't know about 4.7 yet), with the problem becoming apparent after the tabs are moved from their initial positions.

Comment 3 Frank Reininghaus 2011-09-20 21:32:18 UTC

Looks like it might be a duplicate of bug 282017.

Comment 4 Brendon Higgins 2011-09-20 21:46:00 UTC

I prefer the term "manifestation" rather than "duplicate", seeing as my report preceded 282017. ;) But semantics aside, I agree, 282017 does sound like a possible candidate for the cause, or at least being closely related.

Comment 5 Frank Reininghaus 2011-09-22 17:20:07 UTC

You're right, of course. My attention was just drawn to the other bug report because a fix for that one was proposed recently at
https://git.reviewboard.kde.org/r/102628/

I've tried that fix and can confirm that it also works for tab names in Konqueror.

However, the issue you mentioned in comment 2 is not fixed by that patch. This one probably needs fixing in Konqueror, not kdelibs.

Comment 6 Anguo 2012-01-08 17:58:21 UTC

The following is a different bug, or maybe, a different manifestation of the same bug:
bug 290988
See description there for details.

Comment 7 Dawit Alemayehu 2012-01-19 07:48:51 UTC

As Frank stated in comment #5, the original bug report seems to have been addressed as the result of the fix applied for bug #282017. As for the issue you mentioned in comment #2, see the bug report mentioned in comment #6. That one has not yet been addressed.