Fix page jumping back to initial position after an overflow-bounce scroll.

Fix page jumping back to initial position after an overflow-bounce scroll.

This CL is forked from the CL at https://codereview.chromium.org/122093002,
original author thakis. This CL fixes the layout test to correctly
differentiate between the correct and incorrect behaviors.

thakis's CL in turn is a merge of http://trac.webkit.org/changeset/160791 and
http://trac.webkit.org/changeset/160898 from Beth Dakin <bdakin@apple.com>;.

Depends on Chromium CL: https://codereview.chromium.org/283713002/

BUG=330887
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=174427

[erikchen, 2014-05-13 20:40:48]

This CL fixes the unit-test you were trying to write. Please review. :)

[Nico, 2014-05-14 10:53:31]

lgtm, thanks!

Since this merges a WebKit patch, the CL description should credit that
("""Merges http://trac.webkit.org/changeset/160791 and 
http://trac.webkit.org/changeset/160898 from Beth Dakin <bdakin@apple.com>;."""
or similar).

Tests that run for at least 2s due to timeouts are not ideal; maybe we can
refactor the test interface for this to prevent this in the future.

I don't understand why this depends on that chrome CL.

https://codereview.chromium.org/282743002/diff/120001/LayoutTests/rubberbandi...
File LayoutTests/rubberbanding/scroll-bounce-fix.html (right):

https://codereview.chromium.org/282743002/diff/120001/LayoutTests/rubberbandi...
LayoutTests/rubberbanding/scroll-bounce-fix.html:85: }, 2000);
:-/

[erikchen, 2014-05-14 17:43:57]

I've updated the description of this CL, as well as the dependent CL better
describe the purpose of the CLs, correctly attribute original authors, and
reference the relevant bug.

I don't like the 2 second wait either, but I couldn't find another non-invasive
technique that would correctly differentiate between the correct and incorrect
test cases.

I've changed mouseMomentumBegin -> mouseMomentumBegin2 in the only other
rubberbanding layout test, to facilitate the rename operation.

[erikchen, 2014-05-14 17:50:02]

To provide more information on the testing:

When Blink behaves correctly, the view port bounces back to the bottom of the
content over the course of ~1 second. The precise amount that the view port
changes per animation tick is non-deterministic, since it depends on the
"velocity", which depends on the exact timing of the setTimeout() callbacks. 

Problem 1: Find a non-invasive way to determine when the animation has settled.

When Blink behaves incorrectly, it actually fully mimics the behavior of the
correct case. But after the animation has settled, on the next animation tic,
the view port is bounced to the top of the content (the exact location varies).

Problem 2: Checking for the absence of a behavior in a test is generally more
difficult. Furthermore, I didn't want to overspecify the failure case, as I want
to catch other Blink errors.

Suggestions for how to remove the 2 second wait are appreciated.

[erikchen, 2014-05-19 21:01:00]

The CQ bit was checked by erikchen@chromium.org

[commit-bot: I haz the power, 2014-05-19 21:01:16]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/erikchen@chromium.org/282743002/140001

[erikchen, 2014-05-20 00:00:37]

The CQ bit was unchecked by erikchen@chromium.org

[erikchen, 2014-05-20 22:03:40]

The CQ bit was checked by erikchen@chromium.org

[commit-bot: I haz the power, 2014-05-20 22:04:52]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/erikchen@chromium.org/282743002/230001

[commit-bot: I haz the power, 2014-05-20 23:29:24]

Change committed as 174427