Version: 2.0.89 (using KDE 4.5.95) OS: Linux When sort order is set to "By Date/Time" and direction to "Least Recent on Top", one has to scroll down over all the messages every time a folder is open. Reproducible: Always Steps to Reproduce: 1. Set sort order to "By Date/Time" and direction to "Least Recent on Top" 2. Select a folder Actual Results: The start of the message list is shown Expected Results: The end of the message list should be shown, i.e. the most recent message should be available with no need to scroll for it. OS: Linux (x86_64) release 2.6.36-gentoo-r5 Compiler: x86_64-pc-linux-gnu-gcc
Seconded. This bug is super annoying. Also, this is somewhat of a regression from Kmail 1 series, where the message list was at least focused on the last message selected in the folder. In Kmail 2 the last selected message is not remembered between folder changes. IMHO a preferable fix would be one, which would implement both things. I.e. when opening the message list of a mail folder: - Scroll to the message that was selected when the user last switched away from the folder - If such a message is not found (no message has ever been selected, or knowledge of the selected message has disappeared) scroll to show the latest e-mails in the folder Also running Kmail 2.0.89 on KDE 4.6.0
There is also a problem when you actually scroll to the end of the list and then delete/move to other folder the last message and the list loses focus - it then jumps back to the beginning instead of staying at the bottom. It's really annoing and one of the regressions from old kmail.
Git commit 4fab93c985c2ea87499b68ad5822c93e49637e24 by Andreas Hartmetz. Committed on 23/06/2025 at 14:50. Pushed by ahartmetz into branch 'master'. Fix "scrolling lock" to the bottom of the message list view It didn't work for me in some folders. At the time that the previous verticalScrollBar()->value() was taken, minimum and maximum scroll positions were equal (both zero) and so value() was zero, too, interpreted as top scroll position. "Restoring" that position did not give the desired result. Use the sort direction as a tie-breaker instead and *return* the scrolling lock position instead of guessing (badly) in the caller. Additonal observation: the notFirstLoadingJob condition is strange: it was supposed to keep the list scrolled at the top or bottom *only for e-emails arriving after the startup phase* - it doesn't seem to have had that effect anymore and might instead have sometimes prevented the bug that this commit tries to fix properly. Might be possible to remove it now and / or to otherwise restore the old intended behavior for people who want that. Reference: commit c4fea23364fc175c97396a5d3506ebbfa2803de8 in kdepim / svn revision 978098. M +2 -2 messagelist/src/core/model.cpp M +18 -14 messagelist/src/core/view.cpp M +3 -3 messagelist/src/core/view.h https://invent.kde.org/pim/messagelib/-/commit/4fab93c985c2ea87499b68ad5822c93e49637e24
I think it's fixed then :)
Git commit 824a07c785d21cb40f5d49dbb0e8f219514a95a5 by Andreas Hartmetz. Committed on 23/06/2025 at 21:04. Pushed by ahartmetz into branch 'master'. That notFirstLoadingJob mentioned earlier? It's more of a bug now It is true during inital loading of the folder, but false when loading the same folder again by clicking on another one, then the first one again. A situation not too different from first loading from the user POV, except the scroll position didn't stay at the bottom that time, but ended up quite close to the top (very old messages). Tested with ascending order / most recent at bottom. Staying at the top happens more or less by itself, it's the easy case. M +1 -2 messagelist/src/core/view.cpp https://invent.kde.org/pim/messagelib/-/commit/824a07c785d21cb40f5d49dbb0e8f219514a95a5