Bug 166870

Created attachment 26218 [details]
destroyed website after scrolling

Oh... Just posted the bug and now i find a way to reproduce...

This works on a Lenovo 3000 N200 (intel graphics) and a Dell Inspiron 1501
(ati, fglrx driver)
- load http://planet.openmoko.org/ in konqueror. wait for 100% loading
- use the touchpad to scroll to the right end. than use the touchpad to scroll
back to the left end.
- press the page down key once. something animated occures which ends with the
screenshot i attached.

You can reproduce it with a wheelmouse:
- load http://planet.openmoko.org/ in konqueror. wait for 100% loading 
- hold down 'alt' and scroll one step up, than one step down 
- press the page down key once. same effect like above

Version 4.1.00 (KDE 4.1.0) (KDEmod) in ArchLinux i686:

I can confirm this bug.

I have a Dell Inspiron 1525
Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)
xf86-video-intel 2.3.2 driver

With both horizontal scrolling with the touchpad or Alt+scroll with the USB wheelmouse.

After moving the scroll and pressing some keys (like comment 2 said), the page rapidly scroll to the bottom of the page. The scrollbar slider is a the top, but the bottom of the page is displayed. Also moving the scrollbar doesn't move the page (weird)

Created attachment 26508 [details]
Destroyed website after scrolling - Another shot in my config

Created attachment 26509 [details]
Weird scrollbar position and page bug after scrolling bug

I've got the same thing on Kde/Konq 4.1 on my Macbook with 2-fingered scrolling enabled via Xorg.conf... only it copies the image to the South-east, instead of 100% south.

 

Created attachment 27298 [details]
Fixes the bug

I have found two problems with khtml's smooth scrolling.

1 - not resetting all needed data when starting scrolling
2 - no protection against 'backward' scrolling

solving one of this problems would have fixed this bug, but fixing both is even better, I think. ;)

(patch is for current svn. not testet with 4.1, but should work too)

hi Manuel... thanks for the patch!
It works indeed fine for me, however, if the clearing of intermediate steps makes sense, I don't understand the purpose of that change:

-    if (tddx > 0 && tddx < 16) tddx = 16;
-    if (tddy > 0 && tddy < 16) tddy = 16;
-    if (tddx < 0 && tddx > -16) tddx = -16;
-    if (tddy < 0 && tddy > -16) tddy = -16;
+    if (d->dx > 0 && tddx < 16) tddx = 16;
+    if (d->dy > 0 && tddy < 16) tddy = 16;
+    if (d->dx < 0 && tddx > -16) tddx = -16;
+    if (d->dy < 0 && tddy > -16) tddy = -16;

doesn't d->dx > 0 implies tddx > 0 in all cases, and similarly for the other cases? So what's the difference?

(CCing Allan who is the author of the algorithm)

It does only when the intermediate steps are cleared. The original bug comes from the problem that tddx/tddy changed the sign and it scrolls in the wrong way. With clearing the intermediate steps, it isn't needed, but it protects the code from future annoying things.
Hope you understand. I have some problems do describe this in english. ;)

There was a bug like this I solved for vertical scrolling. As far as I know it only exists for horizontal scrolling now (I didn't notice it because I don't have a horizontal mouse-wheel or scrollpad).

I will look at the patch and fix it.

This bug occurs only when you scroll vertical and horizontal. Because if you first scroll, say, horizontal, there stays values in rdx/rddx witch leads to slowly scroll horizontal when you vertical scroll. so, it never reaches the point where dx and dy are zero.

To clarify:
resetting rdx/rdy/rddx/rddy when you start scrolling solves the problem.
The other changes in my patch (in scrollTick) are only to protect against  unpredictable future problems. It prevents that the scrolling speed turns to the wrong way when it reaches zero-speed before reaching dx=dy=0.

Created attachment 27332 [details]
Patch with small simplifications and guards

Since CCBUG apparently doesn't work, I would just like to repeat here, that I commited this patch to trunk. It should fix it as Manual described the issue, but without the same scrolling-pad setup I can't test. So please try it.

(In reply to comment #12)
> Created an attachment (id=27332) [details]
> Patch with small simplifications and guards
> 
> Since CCBUG apparently doesn't work, I would just like to repeat here, that I
> commited this patch to trunk. It should fix it as Manual described the issue,
> but without the same scrolling-pad setup I can't test. So please try it.
> 

This is reproducable also with a wheel-mouse. See comment #2. You only need a site where you can scroll horizontal and vertical (resize konqueror to get this on nearly every site).

Your patch works, the bug is gone.

Created attachment 27352 [details]
Simplify even more

This patch against current svn simplifies it even more. It makes it easily readable and should run faster.

I have this problem on 4.1.1 in Kubuntu 8.04 on a Macbook with two-finger scrolling enabled. The problem seems to happen in all KDE4 apps, but not in KDE3 or other (GTK, Motif, etc) apps.

(In reply to comment #15)
> I have this problem on 4.1.1 in Kubuntu 8.04 on a Macbook with two-finger
> scrolling enabled. The problem seems to happen in all KDE4 apps, but not in
> KDE3 or other (GTK, Motif, etc) apps.
> 

The problem I am talking about was a bug with khtml's smooth scrolling. so it is impossable that this affects parts that are not khtml-part's. So if you have a scrolling bug in other applications you should open an other bug report. But if you have it only in applications which use khtml (konqueror, akregator, kmail, ...) there is no need to do anything because this bug is gone in the next release. ;)