RESOLVED FIXED 142205
REGRESSION(r180902): It broke scrolling in some cases. See bug 142202 for details. (Requested by bdash on #webkit).
https://bugs.webkit.org/show_bug.cgi?id=142205
Summary REGRESSION(r180902): It broke scrolling in some cases. See bug 142202 for det...
WebKit Commit Bot
Reported 2015-03-02 19:24:27 PST
http://trac.webkit.org/changeset/180902 broke the build: It broke scrolling in some cases. See bug 142202 for details. (Requested by bdash on #webkit). This is an automatic bug report generated by webkitbot. If this bug report was created because of a flaky test, please file a bug for the flaky test (if we don't already have one on file) and dup this bug against that bug so that we can track how often these flaky tests fail.
Attachments
ROLLOUT of r180902 (74.14 KB, patch)
2015-03-02 19:24 PST, WebKit Commit Bot
no flags
WebKit Commit Bot
Comment 1 2015-03-02 19:24:57 PST
Created attachment 247737 [details] ROLLOUT of r180902 Any committer can land this patch automatically by marking it commit-queue+. The commit-queue will build and test the patch before landing to ensure that the rollout will be successful. This process takes approximately 15 minutes. If you would like to land the rollout faster, you can use the following command: webkit-patch land-attachment ATTACHMENT_ID where ATTACHMENT_ID is the ID of this attachment.
Mark Rowe (bdash)
Comment 2 2015-03-02 19:26:23 PST
*** Bug 142202 has been marked as a duplicate of this bug. ***
WebKit Commit Bot
Comment 3 2015-03-02 19:30:03 PST
Comment on attachment 247737 [details] ROLLOUT of r180902 Clearing flags on attachment: 247737 Committed r180915: <http://trac.webkit.org/changeset/180915>
WebKit Commit Bot
Comment 4 2015-03-02 19:30:07 PST
All reviewed patches have been landed. Closing bug.
Brent Fulgham
Comment 5 2015-03-03 15:56:45 PST
This bug was caused by an error in my refactoring of ScrollingTreeScrollingNodeMac. The original "snapRubberbandTimer" implementation made sure to notify the scrollingTree that rubber banding was ended, and to reset the content size of the scrolling node. When I consolidated the stop timer methods, I lost this step. This caused the scrolling thread's view of the scrollable area to no longer match the main thread. The scrolling thread then allowed the user to scroll down far past the end of the document. Attempts to build a test that notices this problem are confounded by the fact that querying the DOM for the scroll area size returns the right information (even with this bug) because the main thread copy of the state is correct.
Note You need to log in before you can comment on or make changes to this bug.