Bug 322212

Summary:	incorrect scroll position most of the times when going back or up one folder in populated folders
Product:	[Applications] dolphin	Reporter:	Mihail Atanassov <mi6o.1992>
Component:	view-engine: general	Assignee:	Dolphin Bug Assignee <dolphin-bugs-null>
Status:	RESOLVED FIXED
Severity:	normal
Priority:	NOR
Version:	2.2
Target Milestone:	---
Platform:	openSUSE
OS:	Linux
Latest Commit:	http://commits.kde.org/kde-baseapps/02e412371c10a8e3137a7f782ce52dd6ecdeafe8	Version Fixed In:	4.11.0
Sentry Crash Report:
Attachments:	screenshot of the position the browser returns to

Description Mihail Atanassov 2013-07-10 19:05:40 UTC

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)

Comment 1 Mihail Atanassov 2013-07-10 19:08:19 UTC

Created attachment 81047 [details]
screenshot of the position the browser returns to

These were all made at 64 pixels icon size.

Comment 2 Mihail Atanassov 2013-07-10 19:13:18 UTC

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.

Comment 3 Mihail Atanassov 2013-07-10 19:16:52 UTC

(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.

Comment 4 Frank Reininghaus 2013-07-11 07:32:12 UTC

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.

Comment 5 Frank Reininghaus 2013-07-22 17:18:14 UTC

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

Comment 6 Christoph Feck 2013-07-23 12:57:43 UTC

> 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.

Comment 7 Frank Reininghaus 2013-07-23 13:06:46 UTC

(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?

Comment 8 Christoph Feck 2013-08-10 22:13:20 UTC

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.

Comment 9 Frank Reininghaus 2013-08-12 09:15:56 UTC

(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.