490216 - Inconsistent width of width:100% position:absolute table inside position:relative inline

Status: RESOLVED FIXED

(Core :: Layout: Tables, defect)

Description

[Jesse Ruderman]

Attachment: testcase (dynamic)

This is just layout/reftests/bugs/371561-1.html with some bouncing added, so it might involve some of the same issues as bug 371561 did.

Comment 1

[Jesse Ruderman]

Attachment: reference (static)

Comment 2

[Daniel Holbert [:dholbert]]

Testcase is way skinnier than reference case on Linux, too.  Platform-->All/All
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090425 Minefield/3.6a1pre

Comment 3

[Tony Blackmore]

When used with position absolute Table width "xx%" sizes table to cell content not the surrounding envelope.  Width="100" sizes to the exact cell content" Width "99%" will wrap text to fit.

Comment 4

[Daniel Holbert [:dholbert]]

This is WFM in Firefox 2.  Hence, adding regression keyword.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.18) Gecko/20081029 Firefox/2.0.0.18

Comment 5

[Boris Zbarsky [:bzbarsky]]

Sight unseen, I'd pin reflow branch as the regressing patch.  I'll try to double-check this tomorrow.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Well, the reflow branch landing certainly changed rendering from correct to broken on the dynamic testcase.  In particular, the table became far too wide (NS_INTRINSICSIZE wide, I suspect).  But this was the case for both dynamic and static testcase.

Things stayed that way until the 2007-10-29-04 build.  In the 2007-10-30-04 build, the rendering changed again (I think due to bug 384681) but continued to be the same in both testcases (and wrong in both).  This is how Fx3 shipped.

On trunk, behavior changed again between 2009-01-07-02 (rev 670a3b50dfe0) and 2009-01-08-02 (rev 28488df9e75e), going back to the behavior we used to have right after reflow branch landed.  I have no idea what might have caused this change in painting.  Maybe bug 456219?  The relevant pushlog is http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=670a3b50dfe0&tochange=28488df9e75e if someone cares.

Behavior changed again between 2009-02-24-02 (rev 69c86f3acc5a) and 2009-02-25-02 (rev 8eba35e62d92), which corresponds to landing bug 371561.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Oh, and that last change gave us the current behavior: correct in the static case, but not the dynamic one.

Comment 8

[Boris Zbarsky [:bzbarsky]]

So in the dynamic case when we go to InitConstraints on the table inner frame, the mRect of the inline is all zeros, and -1 was passed in for the containing block width and height by the caller.  The only reason the table doesn't end up with width 0 is that it doesn't allow itself to shrink below its min-intrinsic width.

In the static case, the mRect is still all zero, but the passed-in sizes are not -1.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Er, scratch that.  The passed-in sizes are fine in all cases, for the actual positioned frame (the outer frame).  In the static case, we reflow the abs pos table twice, for whatever reason.  The first time we get the sizing wrong but the second time the inline frame's mRect has been updated (from the first reflow), so we get the right thing happening.

In the dynamic case, after the style change there is only one reflow.

So this would all sort of work if the inner table used the outer as a cb, but it doesn't....

I suppose we could store the passed-in containing block dimensions in the reflow state (of the outer table, in this case) and then look at our parent reflow state in the inner table.  That sounds pretty hacky, but then again this whole setup where the containing block for the inner table is the cb of the outer table is hacky as long as the cb can push layout info to kids instead of just being asked for it (which is the case with the containing block size arguments to the reflow state constructor and init).

Comment 10

[Boris Zbarsky [:bzbarsky]]

This got fixed in this range: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=30ea2905130e85f9e1d8d56fa3097901eec6514b&tochange=67cd1ee26f2661fa5efe3d952485ab3c89af4271

Looks like bug 667079 fixed this, based on the bug description there.