Bug 118439 - Fix r152265: FrameView's pagination mode is only one of two, and the logic was totally wrong
Summary: Fix r152265: FrameView's pagination mode is only one of two, and the logic wa...
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-07-05 17:30 PDT by Tim Horton
Modified: 2013-07-05 19:20 PDT (History)
4 users (show)

See Also:

Attachments
patch (5.70 KB, patch)
2013-07-05 17:48 PDT, Tim Horton 		andersca: 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-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