I have many folders that do not fit in a single window height in Details view mode. If I have a file marked near the bottom of the list in one of them and go back (most of the time to the parent folder), the scroll position is not reset to show the top of the (parent) folder; instead, I view the bottom part of it, or some intermediate location, depending on the relative folder populations. This happens often enough (60-70% of the times) to be moderately annoying. If you need any more info, I'm happy to supply it. If you cannot reproduce it, I can record a video showing the exact situation. Reproducible: Sometimes Steps to Reproduce: 1. Open a well-populated folder (folder 1) in details view. 2. Open a well-populated subfolder (folder 2). 3. Scroll to the bottom of the folder, pick one file and select it (now is the time to mention I'm using double clicks to open). 4. Go back or up one folder. 5. Do 2-3 times if necessary Actual Results: I'm viewing the bottom of folder 1. Expected Results: I was supposed to view the top of folder 1. (Happens 30-40% of the time) Running on KDE 4.10.5 "release 4" Dolphin 2.2 openSuSE 12.3 x86_64 For completeness sake, my folder contents were as follows: folder 1: 22 folders 7 files; folder2: 38 files. When you return to folder 1, the scrollbar is not at the very bottom, but rather 5-10px above its bottom-most position (I'll try and post a screenshot shortly)
Created attachment 81047 [details] screenshot of the position the browser returns to These were all made at 64 pixels icon size.
Revising the steps to reproduce, the problem is a little bit different (where's the edit button? :)): 1. Open folder1 (e.g. /home/user/Documents) 2. Open folder2 (e.g. /home/user/Documents/unsorted) 3. Scroll to the bottom 4. Turn the scroll wheel as if to scroll down more (of course, nothing happens) 5. Go to the previous folder, and hey presto, we're at the bottom again. 100% reproducible.
(In reply to comment #2) > 5. Go to the previous folder, and hey presto, we're at the bottom again. > 100% reproducible. Same thing happens when going back more than one folder when using breadcrumbs. As long as the target folder has more files than can fit in a window height.
Thanks for the bug report! I can confirm the problem (when trying to scroll further down using the mouse wheel in 'folder 2', see comment 2). I haven't noticed this before - very strange bug! BTW, it's not 'Details View' specific. I can also reproduce this in Icons View.
Git commit 02e412371c10a8e3137a7f782ce52dd6ecdeafe8 by Frank Reininghaus. Committed on 22/07/2013 at 17:16. Pushed by freininghaus into branch 'KDE/4.11'. Do not try to smooth-scroll past the end of the view KItemListSmoothScroller::scrollTo(qreal position) did not check if 'position' is a valid value. Even if the view is scrolled to the bottom already, it tried to scroll further and activated "smooth scrolling" when the mouse wheel is used. Because it never got out of the "smooth scrolling" state then, it got confused when changing the directory, and restoring the correct scroll offset could fail. FIXED-IN: 4.11.0 REVIEW: 111557 M +7 -2 dolphin/src/kitemviews/private/kitemlistsmoothscroller.cpp http://commits.kde.org/kde-baseapps/02e412371c10a8e3137a7f782ce52dd6ecdeafe8
> 4. Go back or up one folder. This works good now when going "back", but not when going "up". Those might be totally different things internally, but just asking if it was intended, that the committed patch was not supposed to (or cannot) fix the "up" case.
(In reply to comment #6) > This works good now when going "back", but not when going "up". When I go "up", the view is always scrolled to the top, as expected. Could you provide steps to reproduce the problem?
If this is the expected behavior, I will just have to remember to "go back" instead of "go up" when revisiting the folder I came from.
(In reply to comment #8) > If this is the expected behavior, I will just have to remember to "go back" > instead of "go up" when revisiting the folder I came from. I know that other file managers do restore the scroll position when going "up". But then I wonder why they have separate actions for "back" and "up" at all. There have been discussions about this in the past, see, e.g., bug 193549.