RESOLVED FIXED 109497
FrameView::setScrollPosition should clamp scroll position before handing it to ScrollingCoordinator instead of depending on ScrollView to do this 
https://bugs.webkit.org/show_bug.cgi?id=109497
Summary FrameView::setScrollPosition should clamp scroll position before handing it t...
Tim Horton
Reported 2013-02-11 15:05:56 PST
Steps to Reproduce: Try to type rapidly into the "Homepage Title Format" field in the squarespace admin console with ToT WebKit. <rdar://problem/12631789>
Attachments
patch (8.57 KB, patch)
2013-02-11 15:10 PST, Tim Horton 		simon.fraser: review+
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Tim Horton
Comment 1 2013-02-11 15:06:23 PST
Uhh, if you follow the steps to reproduce, you see flashing. Because we're scrolling out of view for one frame.
Tim Horton
Comment 2 2013-02-11 15:10:22 PST
Created attachment 187690 [details] patch
Tim Horton
Comment 3 2013-02-11 15:16:29 PST
http://trac.webkit.org/changeset/142526
Alexey Proskuryakov
Comment 4 2013-02-11 17:28:20 PST
Is this related to bug 105902?
Tim Horton
Comment 5 2013-02-11 17:29:46 PST
I don't think so, no.
John Knottenbelt
Comment 6 2013-02-27 04:23:07 PST
Comment on attachment 187690 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=187690&action=review > Source/WebCore/page/FrameView.cpp:1783 > + if (newScrollPosition == scrollPosition()) In Safari Mobile, when the page loads, is the scrollPosition() already at (0,0), or is it at some other value? If it starts off at (0,0), this change stops window.scrollTo(0,0) from hiding the URL bar. window.scrollTo(0,1), would be unaffected. Any information you can provide here would be very helpful, especially with respect to https://bugs.webkit.org/show_bug.cgi?id=107026 Thanks!
Note You need to log in before you can comment on or make changes to this bug.