Summary: | Frame Refactor: Move forceLayout,adjustPageHeight,forceLa. to FrameView | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Holger Freyther <zecke> | ||||
Component: | WebKit Misc. | Assignee: | Nobody <webkit-unassigned> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | ||||||
Priority: | P2 | ||||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | Mac | ||||||
OS: | OS X 10.5 | ||||||
Attachments: |
|
Description
Holger Freyther
2009-01-20 03:55:14 PST
Created attachment 26858 [details]
Carry out the move
Tested on the mac. Zoom functions were left in Frame due the state they store in the Frame (which would have to be saved/restored on navigation and FrameView creation)
Comment on attachment 26858 [details] Carry out the move > + // We cannot unschedule a pending relayout, since the force can be called with > + // a tiny rectangle from a drawRect update. By unscheduling we in effect > + // "validate" and stop the necessary full repaint from occurring. Basically any basic > + // append/remove DHTML is broken by this call. For now, I have removed the optimization > + // until we have a better invalidation stategy. -dwh > + //v->unscheduleRelayout(); The "v->" no longer makes sense here. > if (minPageWidth > 0.0) > - coreFrame->forceLayoutWithPageWidthRange(minPageWidth, maxPageWidth, adjustViewSize); > + coreFrame->view()->forceLayoutWithPageWidthRange(minPageWidth, maxPageWidth, adjustViewSize); > else { > - coreFrame->forceLayout(!adjustViewSize); > + coreFrame->view()->forceLayout(!adjustViewSize); > if (adjustViewSize) > coreFrame->view()->adjustViewSize(); > } No need to null-check view() here? Are you sure? r=me |