Bug 109497

Summary:

FrameView::setScrollPosition should clamp scroll position before handing it to ScrollingCoordinator instead of depending on ScrollView to do this

Product:

WebKit

Reporter:

Tim Horton <thorton>

Component:

Layout and Rendering

Assignee:

Tim Horton <thorton>

Status:

RESOLVED FIXED

Severity:

Normal

CC:

andersca, ap, bdakin, sam, simon.fraser

Priority:

Keywords:

InRadar

Version:

528+ (Nightly build)

Hardware:

Unspecified

OS:

Unspecified

Attachments:

Description	Flags
patch	simon.fraser: review+

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!