To reproduce: 0. Enable tiled drawing 1. Go to http://www.webkit.org/blog/ 2. Scroll down a bit using a 1-finger swipe on a Magic Mouse (I haven't tested other mice) 3. Press the Down arrow The page jumps back up to the top, then scrolls down one "arrow's worth". It's as if there are two different scroll offsets being tracked: one for gesture scrolls, and one for keyboard scrolls.
<rdar://problem/10910908>
<rdar://problem/10866273>
Created attachment 129371 [details] Patch
Comment on attachment 129371 [details] Patch I think the ScrollableArea should be the one with a concept of the scroll position and the animator simply queries it. That can be a clean up though.
Committed r109183: <http://trac.webkit.org/changeset/109183>
This seems to have broken a bunch of Chromium scrolling tests: https://bugs.webkit.org/show_bug.cgi?id=79878. There are links to the failures from there, but the short story is that the Chromium tests aren't seeing any rubberbanding. Does it seem reasonable that this change would cause such regressions?
(In reply to comment #6) > This seems to have broken a bunch of Chromium scrolling tests: https://bugs.webkit.org/show_bug.cgi?id=79878. There are links to the failures from there, but the short story is that the Chromium tests aren't seeing any rubberbanding. Does it seem reasonable that this change would cause such regressions? Weird - I'll take a look right away.