Bug 118439

Summary:

Fix r152265: FrameView's pagination mode is only one of two, and the logic was totally wrong

Product:

WebKit

Reporter:

Tim Horton <thorton>

Component:

Layout and Rendering

Assignee:

Tim Horton <thorton>

Status:

RESOLVED FIXED

Severity:

Normal

CC:

andersca, bdakin, simon.fraser, webkit-bug-importer

Priority:

Keywords:

InRadar

Version:

528+ (Nightly build)

Hardware:

Unspecified

OS:

Unspecified

Attachments:

Description	Flags
patch	andersca: review+

Description Tim Horton 2013-07-05 17:30:19 PDT

The test was only passing by sheer happenstance (FrameView's pagination is the CSS one, so it was set to Unpaginated, so the totally-broken logic happened to cause the clamping not to happen). So, use both FrameView's and Page's. And fix the logic (we wanted to NOT clamp in the pagination case).

Also, I found ways (with RTL text) that even left-to-right and top-to-bottom pagination can be broken here, so expand to all "pagination enabled" non-0-scrollOrigin states.

Also, the test was broken because DrawingAreaImpl doesn't know what to do with a 40000 px wide view (and just asserts in SharedMemory code and thus makes the test time out). And DidFirstPaintAfterSuppressedIncrementalRendering doesn't fire if the window is offscreen. And EXPECT_JS_EQ is pretty cool.

Basically, rewrite the patch. It deserves it.

Comment 1 Radar WebKit Bug Importer 2013-07-05 17:30:42 PDT

<rdar://problem/14366120>

Comment 2 Tim Horton 2013-07-05 17:48:53 PDT

Created attachment 206179 [details]
patch

Comment 3 Tim Horton 2013-07-05 19:20:39 PDT

http://trac.webkit.org/changeset/152433