Bug 79249 – With tiled drawing enabled, pressing Down arrow after scrolling via mouse gesture causes page to jump back up to top

• Status: RESOLVED
• Resolution: FIXED
• Component: Layout and Rendering

[Adam Roben (:aroben)]

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.

[Radar WebKit Bug Importer]

<rdar://problem/10910908>

[Adam Roben (:aroben)]

<rdar://problem/10866273>

[Anders Carlsson]

Created attachment 129371 [details]
Patch

[Sam Weinig]

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.

[Anders Carlsson]

Committed r109183: <http://trac.webkit.org/changeset/109183>

[Adam Klein]

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?

[Anders Carlsson]

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