|Summary:||very annoying scrolling bug sometimes occures if i use se scrollbars on my synaptics touchpad|
|Product:||[Applications] konqueror||Reporter:||Manuel Mommertz <2Kmm>|
|Component:||khtml||Assignee:||Konqueror Developers <konq-bugs>|
|Severity:||normal||CC:||andresbajotierra, fadingdust, germain, katrina.niolet, kde|
|Latest Commit:||Version Fixed In:|
destroyed website after scrolling
Destroyed website after scrolling - Another shot in my config
Weird scrollbar position and page bug after scrolling bug
Fixes the bug
Patch with small simplifications and guards
Simplify even more
Description Manuel Mommertz 2008-07-17 19:24:42 UTC
Version: (using Devel) Installed from: Compiled sources OS: Linux Sometimes, if i scroll with the horizontal or vertical scrollbars on my synaptics touchpad (more often with vertical scrolling) there is a effect like the content is on ice ore something. it doesn't stop scrolling if i stop moving but it moves on, changes the angel of scrolling in a circular way. and than scrolls away complet and just leave artefacts. i can't describe it and i havn't found a way to reproduce. its just to seldom. i try to take a screenshot the next time i get it. what i can say: i get it with an ati and an intel graphics chip. with gentoo and with suse. so it doesn't look like a driver problem. (don't know if it occures with desktop-effects off)
Comment 1 Manuel Mommertz 2008-07-17 19:39:01 UTC
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.
Comment 2 Manuel Mommertz 2008-07-18 01:31:14 UTC
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
Comment 3 Dario Andres 2008-07-30 22:34:49 UTC
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)
Comment 4 Dario Andres 2008-07-30 22:35:39 UTC
Created attachment 26508 [details] Destroyed website after scrolling - Another shot in my config
Comment 5 Dario Andres 2008-07-30 22:36:29 UTC
Created attachment 26509 [details] Weird scrollbar position and page bug after scrolling bug
Comment 6 mark 2008-08-19 04:07:15 UTC
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.
Comment 7 Manuel Mommertz 2008-09-08 00:04:44 UTC
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)
Comment 8 Germain Garand 2008-09-09 01:45:23 UTC
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)
Comment 9 Manuel Mommertz 2008-09-09 08:44:09 UTC
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. ;)
Comment 10 Allan Sandfeld 2008-09-09 09:28:30 UTC
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.
Comment 11 Manuel Mommertz 2008-09-09 09:38:09 UTC
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.
Comment 12 Allan Sandfeld 2008-09-09 10:46:52 UTC
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.
Comment 13 Manuel Mommertz 2008-09-10 16:21:51 UTC
(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.
Comment 14 Manuel Mommertz 2008-09-10 16:27:37 UTC
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.
Comment 15 Katrina Niolet 2008-09-18 20:53:03 UTC
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.
Comment 16 Manuel Mommertz 2008-09-18 21:22:41 UTC
(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. ;)