Bug 109497 - FrameView::setScrollPosition should clamp scroll position before handing it to ScrollingCoordinator instead of depending on ScrollView to do this
Summary: FrameView::setScrollPosition should clamp scroll position before handing it t...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Tim Horton
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2013-02-11 15:05 PST by Tim Horton
Modified: 2013-02-27 04:23 PST (History)
5 users (show)

See Also:

Attachments
patch (8.57 KB, patch)
2013-02-11 15:10 PST, Tim Horton 		simon.fraser: review+
Details | Formatted Diff | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Tim Horton 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>
Comment 1 Tim Horton 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.
Comment 2 Tim Horton 2013-02-11 15:10:22 PST 
Created attachment 187690 [details]
patch
Comment 3 Tim Horton 2013-02-11 15:16:29 PST 
http://trac.webkit.org/changeset/142526
Comment 4 Alexey Proskuryakov 2013-02-11 17:28:20 PST 
Is this related to bug 105902?
Comment 5 Tim Horton 2013-02-11 17:29:46 PST 
I don't think so, no.
Comment 6 John Knottenbelt 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!