Bug 262638

Summary:	Multiple selection of files using the "shift key" selects wrong files!
Product:	[Applications] dolphin	Reporter:	Patrick Tanz <p1703>
Component:	view-engine: details mode	Assignee:	Peter Penz <peter.penz19>
Status:	RESOLVED FIXED
Severity:	major	CC:	frank78ac
Priority:	NOR	Keywords:	investigated
Version:	16.12.2
Target Milestone:	---
Platform:	Ubuntu
OS:	Linux
Latest Commit:		Version Fixed In:	4.8.0
Sentry Crash Report:
Attachments:	Qt-only testcase Possible patch (first try)

Description Patrick Tanz 2011-01-09 11:10:48 UTC

Version: unspecified (using KDE 4.5.5)
OS: Linux

I used Dolphin in details view - maybe this bug happens in other views, too.

A single file is selected by mouse click. Then new files are created within the same folder by another process - the file names of some new files are sorted before the already selected file. Until now, everthing seems to be fine. But if you see the selected file and you want so select the two following files too, using the shift key and mouse click, other files are selected, too!

This is very dangerous, because if you don't notice this selection issue and delete these files, you will lose data!

Reproducible: Always

Steps to Reproduce:
Hint: I used Dolphin in details view - maybe this bug happens in other views, too!

1. preparation:
Files are sorted alphabetically by name, so this forces newly created files to be sorted automatically in current view. Open a folder which contains several files. Select a single file in the middle of the current folder by a mouse click.

2. cause the error:
Other files must be created within this folder by other processes (download files with Firefox or extract files with Ark). The new file names must be sorted _before_ the already selected file - so download or extract such files.

3. show the bug:
Watch your already selected file in Dolphin (maybe you must scroll now). Use the shift key and a mouse click on one of the following files to select all files from your previously selected file to your currently clicked file.

Actual Results:
Not only the intended files are selected, but the number of newly created files before the previously selected single file are additionally selected.

Expected Results:
Only the files between previously selected single file and currently clicked file should be selected.

OS: Linux (x86_64) release 2.6.35-24-generic
Compiler: cc
Kubuntu Maverrick

This is very dangerous, because if you don't notice this selection issue and delete these files, you will lose data! This happend already to me!

I didn't watch the source code, but I think, selecting a file sets an index to this selection and when other files are created within that folder, this index is not up-to-date anymore. This should be the cause of this maloperation.

Comment 1 Frank Reininghaus 2011-01-09 18:01:00 UTC

Thanks for your bug report. How exactly do you select the first file? Do you really just click it (in this case, you've probably enabled the "double-click" mode, i.e., open files with a double-click), do you click on the selection marker ("+") on the file icon, or do you Control-click it?

Comment 2 Patrick Tanz 2011-01-09 18:33:54 UTC

Yes, I'm using doubleclick mode for opening files. So I initially selected the file by a single click on the file name. For the second click after creating the new files, I held the shift key and clicked again on the file name of a file some positions below to select all files between first and second click.

Comment 3 Peter Penz 2011-01-14 21:13:06 UTC

I could reproduce the issue:
- It happens only if double-click is used
- It occurs in all views (I still leave it assigned to "details-view" though)

Comment 4 Frank Reininghaus 2011-02-25 15:36:36 UTC

I can also reproduce it in single-click mode if I Control-click the first item.

Another way to reproduce is by resorting: Control-click an item, change the sort order, Shift-click another item.

I think that this must be fixed in QAbstractItemView. This class keeps the position of the first clicked item in its private member d->pressedPosition. This member is not updated when the position of the item changes. One possibility might be to use a QPersistentModelIndex to keep track of the item which has been clicked first.

Comment 5 Frank Reininghaus 2011-03-03 00:20:06 UTC

Created attachment 57628 [details]
Qt-only testcase

Comment 6 Frank Reininghaus 2011-03-03 00:22:25 UTC

Created attachment 57629 [details]
Possible patch (first try)

This patch fixes it for me, but unfortunately, it breaks an existing unit test (tst_QTableView::taskQTBUG_4516_clickOnRichTextLabel), so it seems that some more work is required.

Comment 7 Frank Reininghaus 2011-03-08 23:15:41 UTC

I've created an upstream bug report: 
http://bugreports.qt.nokia.com/browse/QTBUG-18009

Comment 8 Frank Reininghaus 2011-08-10 08:40:53 UTC

In KDE 4.8, Dolphin's view engine will not be based on Qt's item views anymore. This enables us to fix this issue on our own :-) I'll push a commit that fixes this problem in a minute.

Comment 9 Frank Reininghaus 2011-08-10 08:41:10 UTC

Git commit fae7b960e209d47159ea7ef94be95b0cedd6af68 by Frank Reininghaus.
Committed on 10/08/2011 at 10:38.
Pushed by freininghaus into branch 'master'.

Update the anchor item when items are added or removed

If items are added or removed in the model, not only the
current item, but also the anchor item, which is the
starting point for any selections via Shift+Click or
Shift+Key, needs to be updated.
BUG: 262638
FIXED-IN: 4.8.0

M  +30   -0    dolphin/src/kitemviews/kitemlistselectionmanager.cpp
M  +36   -0    dolphin/src/tests/kitemlistselectionmanagertest.cpp

http://commits.kde.org/kde-baseapps/fae7b960e209d47159ea7ef94be95b0cedd6af68