Open Bug 1240361 Opened 8 years ago Updated 2 years ago

Does not get clientHeight in a looped function in a iframe


(Core :: Layout, defect)

43 Branch




(Reporter: stemind, Unassigned)



(Keywords: regression)


(2 files)

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.111 Safari/537.36

Steps to reproduce:

Surf and log in 
username is
password is

Now you are in the editor (backend) of the site

Bug: In Firefox the two iframes on the left are not resized (height) as long you do not resize the main window manually. This problem occurred with a Firefox update approx. one month ago. Does work in all other browsers.

Actual results:

Height of the two iframes are not done according to clientHeight (this value is taken from a looping function)

Expected results:

See in other browsers: Height of the two iframes are done according to clientHeight
the two iframes on the RIGHT, not on the left.
Reg range:
Blocks: 1209994
Component: Untriaged → Layout
Ever confirmed: true
Flags: needinfo?(roc)
Keywords: regression
OS: Unspecified → All
Product: Firefox → Core
Hardware: Unspecified → All
This works for me in Nightly. Loic, how about you?
Flags: needinfo?(roc) → needinfo?(epinal99-bugzilla2)
Still broken for me with Nightly on Win 7.
Flags: needinfo?(epinal99-bugzilla2)
OK, the problem here is that an nsTableCellFrame is getting reflowed with one mComputedHeight and then reflowed with a different mComputedHeight, but in the second reflow aReflowState.IsBResize() is false.
I do not understand table reflow well enough to fix this. We get nsTableCellFrame::Reflow with aReflowState.mComputedHeight == 46560 and aReflowState.mFlags.mIsBResize=1. After that reflow, but in the same reflow of the rowgroup, the height of the nsTableCellFrame is set to 50520 with this call stack:

#0  0x00007f803ad306a4 in nsIFrame::SetRect(nsRect const&) (this=0x7f8009ce54f0, aRect=...)
    at /home/roc/mozilla-inbound/layout/generic/nsIFrame.h:730
#1  0x00007f803ad306d2 in nsIFrame::SetSize(nsSize const&) (this=this@entry=0x7f8009ce54f0, aSize=...)
    at /home/roc/mozilla-inbound/layout/generic/nsIFrame.h:781
#2  0x00007f803ad30738 in nsIFrame::SetSize(mozilla::WritingMode, mozilla::LogicalSize const&) (this=this@entry=0x7f8009ce54f0, aWritingMode=..., aWritingMode@entry=..., aSize=...)
    at /home/roc/mozilla-inbound/layout/generic/nsIFrame.h:772
#3  0x00007f803adc3b44 in nsTableRowFrame::DidResize() (this=this@entry=0x7f8009ce3438)
    at /home/roc/mozilla-inbound/layout/tables/nsTableRowFrame.cpp:376
#4  0x00007f803adc3c2c in nsTableRowGroupFrame::DidResizeRows(nsHTMLReflowMetrics&) (this=this@entry=0x7f8009ce2fc8, aDesiredSize=...)
    at /home/roc/mozilla-inbound/layout/tables/nsTableRowGroupFrame.cpp:523
#5  0x00007f803adc8243 in nsTableRowGroupFrame::CalculateRowBSizes(nsPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState const&) (this=this@entry=0x7f8009ce2fc8, aPresContext=aPresContext@entry=0x7f800dce5800, aDesiredSize=..., aReflowState=...)
    at /home/roc/mozilla-inbound/layout/tables/nsTableRowGroupFrame.cpp:826
#6  0x00007f803adc89c2 in nsTableRowGroupFrame::ReflowChildren(nsPresContext*, nsHTMLReflowMetrics&, nsRowGroupReflowState&, unsigned int&, bool*) (this=this@entry=0x7f8009ce2fc8, aPresContext=aPresContext@entry=0x7f800dce5800, aDesiredSize=..., aReflowState=..., aStatus=@0x7ffceef5529c: 0, aPageBreakBeforeEnd=aPageBreakBeforeEnd@entry=0x7ffceef5479f)
    at /home/roc/mozilla-inbound/layout/tables/nsTableRowGroupFrame.cpp:470

But nothing around here seems to trigger reflow of the table cell or its %-height descendants. It seems to me that it's incorrect to update the height of the cell without triggering reflow of %-height descendants, so I don't know how this is supposed to work.
Flags: needinfo?(dbaron)
This reflow is followed by another reflow of the table (perhaps because I'm resizing the window and generating a lot of reflows). In that later reflow's reflow of the table cell, aReflowState.mComputedHeight matches the cell height computed by the CalculateRowBSizes in the previous table reflow. Because those heights match, the post-bug-1209994 InitResizeFlags code
    SetBResize(frame->BSize(wm) !=
               ComputedBSize() + ComputedLogicalBorderPadding().BStartEnd(wm));
clears the BResize flag even though the row's BResize flag is true.

Before bug 1209994, InitResizeFlags would always set the cell's BResize flag to match the row's BResize flag.

I could easily fix this by partially reverting bug 1209994 by changing the "if (mCBReflowState && frame->IsBlockWrapper())" to include table cells, but I don't understand why that would be correct.
Chances are, the fix for bug 1263845 will incidentally fix this bug, by virtue of being a bit overbroad.
Depends on: 1263845
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.