iframe w/ innerHeight=75 gets body w/ clientHeight=4

[Germain Garand]

Le Lundi 15 Novembre 2004 18:13, Koos Vriezen a écrit :
> On Mon, Nov 15, 2004 at 12:07:37PM +0000, Germain Garand wrote:
> > Le Lundi 08 Novembre 2004 22:32, Koos Vriezen a écrit :
> > > No, doesn't look like it .. because in my case the numbers are right.
> > > The problem is that the body and so its table and so its iframe are
> > > having a hight of 1, whereas the surrounding window is normally sized
> > > (say 300).
> >
> > Hi Koos!
> >
> > I found out it's a combined problem of table cells missing a dirtying
> > when percent childs are involved, and of accumulated bogus resizes that
> > have been posted on widgets, but do not reflect the final layout (there
> > are transitory dry-run layouts for table cells, and those can lead
> > percent childs to be zero height before rows are fully laid out).
> >
> > I believe the attached is safe enough for backport, and it fixes a lot of
> > frame flickering instances on resize... mmh, what do you think?
>
> Thanks!, it seem to work now (tried your patch from follow up mail).
>
> I can't really judge your patch (table layouting is not my cup of tea),

basically, the meat of the render_table change is just adapted from WebCore 
and doesn't change much the flow.
CCing: Allan, could you possibly review this, so it can go to branch?

> but it does look like a waste to resize a widget and later on filter it
> out again. I guess it's not possible to prevent resizing in the first
> place? 

yes, the problem is we don't know before hand if a table cell layout will be 
definitive or just transitory, so it's much cheaper to cancel the event in 
those few cases than to have to do two separate passes for layout and for 
widget resizes everywhere.

Greetings,
Germain