Version: (using KDE 4.2.98) Compiler: gcc (SUSE Linux) 4.3.2 [gcc-4_3-branch revision 141291] platform x86_64 OS: Linux Installed from: SuSE RPMs This both happens in standalone KMail or being integrated within Kontact (which I use most of the time). I have tested it with the plain standard inbox, fed via POP3 from gmx, as well as a disconnected IMAP inbox from the local Kolab instance. Starting with a full Inbox (or any other folder consisting of both already read and unread mails) I start to select unread mails in order to later dispose of them or move them into different folders. Skimming through some mails via keyboard and selecting them in the process (by holding shift pressed) I then scroll down and shift-click on another one to select all in between. Inconsistently it sometimes does not have the wanted effect of getting them all selected but instead all mails downwards up to the end of the list including the one I just clicked on get selected. Those already selected before will stay selected. Due to its irregular nature this behaviour is hard to describe and, seemingly, only happens with read and unread mails in the same folder. And it only happens when the folder holds more mails than can be shown at the moment, e.g. the scrollbar is visible. It does not happen, at least I have not yet experienced it, when selecting purely via mouse and ctrl & shift modfiers. So it does not seem to be a general problem with the selection model.
I can confirm this! Have hat it several times that selection with the shift key does not work as expected.
Bye the way, it happend from KDE 4.3 to 4.4.0 for me
See for a similar bug report http://bugs.gentoo.org/show_bug.cgi?id=294618
Using Kontact 4.7.4 on KDE 4.7.4 (openSUSE 11.4 64bit) the bug is still present. But I can at least narrow it down a bit: This only happens if you switch to a mail folder via the folder tree without giving it focus directly (with a mouse click or the tab key). If you then start shift-selecting mails and delete them, the selection model seems to have been updated correctly and a random selection of mails is deleted. Most often this will happen for a spam folder which has no previous read messages.
Thank you for taking the time to file a bug report. KMail2 was released in 2011, and the entire code base went through significant changes. We are currently in the process of porting to Qt5 and KF5. It is unlikely that these bugs are still valid in KMail2. We welcome you to try out KMail 2 with the KDE 4.14 release and give your feedback.
I still experience this in the latest 4.14.6. Exact steps to reproduce: - select a folder with a few messages and select the top message with the mouse if not selected already - press Shift+Cursor down to mark the message below as well - press Del or Shift+Del and confirm the deletion if necessary The two topmost messages should disappear now, the third one should be on top now and selected - now press Shift+Cursor down again The two topmost messages should be marked now, but in reality the topmost three will be selected. IOW, the actual cursor position was still at line #2 as it was before the deletion, but line#1 was actually selected and displayed (as it should be).
This bug has never been confirmed for a KDE PIM version that is based on KDE Frameworks (5.x). Those versions differ significantly from the old 4.x series. Therefore, I plan to close it in around two or three months. In the meantime, it is set to WAITINGFORINFO to give reporters the oportunity to check if it is still valid. As soon as someone confirms it for a recent version (at least 5.1, ideally even more recent), I'll gladly reopen it. Please understand that we lack the manpower to triage bugs reported for versions almost two years beyond their end of life.
Even after extensive testing, I can't reproduce this bug with the recent versions of Kmail (5.5.2 curently) any more (of which I'm very glad). So it seems to have vanished during the change to Frameworks.