Move the following methods to FrameView: void forceLayout(bool allowSubtree = false); void forceLayoutWithPageWidthRange(float minPageWidth, float maxPageWidth, bool adjustViewSize); void adjustPageHeight(float* newBottom, float oldTop, float oldBottom, float bottomLimit);
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
Landed in r40473. I added a null check for the view.