Bug 23428 – Frame Refactor: Move forceLayout,adjustPageHeight,forceLa. to FrameView

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKit Misc.

[Holger Freyther]

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);

[Holger Freyther]

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)

[Darin Adler]

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

[Holger Freyther]

Landed in r40473. I added a null check for the view.