1240361 - Does not get clientHeight in a looped function in a iframe

Status: NEW

(Core :: Layout, defect)

Description

[stemind]

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 http://goo.gl/DgFyXM and log in 
username is
Temp
password is
FirstPassword7

Now you are in the editor (backend) of the site 
http://yuba.ch/TEMP/u5test/

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

Comment 1

[stemind]

the two iframes on the RIGHT, not on the left.

Comment 2

[stemind]

Attachment: Screenshot of the situation: Firefox 34 does not maximize height of two iframes

Comment 3

[Loic]

Reg range:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=789a931f4344ad2d36a8e7bb92634b618d4e3b58&tochange=beb4cf7d167970d5c774bfe903211e8d58633829

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

This works for me in Nightly. Loic, how about you?

Comment 5

[Loic]

Attachment: Screen Shot 2016-02-11 at 23.17.55.png

Still broken for me with Nightly on Win 7.

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Chances are, the fix for bug 1263845 will incidentally fix this bug, by virtue of being a bit overbroad.