Test 1322843-1[a-d] fail before part 2, while the other two tests fail
before patch for bug 1260031.
MozReview-Commit-ID: 9QfBvtwQOvP
--HG--
extra : rebase_source : d42b2ace21fb2a9e896f89f97b01c2e0584c7313
In nsBlockFrame::PlaceLine(), we query the float available space by
using the line's BSize(), which may cause the line to reflow again due
to available space shrunk.
The first issue lies in the second reflow. That is, we do not leverage
the line's BSize() computed in the first reflow to query the float
available space when updating the inline reflow engine in
BlockReflowInput::AddFloat(). So some tall inline elements could still
overlap the floats as in the first reflow.
To solve this, we cache current line's BSize so that it could be
used to update the inline reflow engine when redo the line.
Another issue is in nsBlockFrame::PlaceLine(). When determined whether
the available space is shrunk, we use the float manager's state *before*
placing the line. So if current line has floats, they're not considered.
To solve this, we use the current set of floats to get the float available
space for comparison, and leave the original aFloatAvailableSpace to provide
the information when redoing the line.
MozReview-Commit-ID: GqqNlphgxYS
--HG--
extra : rebase_source : e2c64ab1ac363c7a08e532dc043bee69d6455049
What's happening here is that we enter an infinite loop by oscillating
between two states. The code assumes that (a) the available space will
never grow, only stay the same or shrink, and (b) that we should break
out of the loop if it stays the same. This also means we hit the
assertion about the available space growing every other time through the
loop.
This is in the inner loop in nsBlockFrame::ReflowBlockFrame that was
introduced in https://hg.mozilla.org/mozilla-central/rev/80ef9bb2c2e9 .
The problem is fundamentally a logic error in that code. The makes the
assumption that if you reduce the width available to a block formatting
context or replaced block-level element, its height does not shrink.
(The "replaced block" (really block formatting context) in this case, as
in the original testcase, is a scroll frame. I didn't debug the
original testcase enough to figure out what caused its sizing
characteristics, although a percentage-width image does seem like the
most likely candidate.)
Without the patch, the reftest test (but not reference) hangs, as does
the semi-simplified test in the bug (given a narrow window).
With the patch, neither the semi-simplified test in the bug nor the
reference hangs, and the reftest passes.
--HG--
extra : commitid : APy8PfXlvvz
The change to the 427129-table-caption test was just to make the
reference match the test.
The change to the other 427129 tests was duplicating the test that
failed, adjusting the reference for one version of it (no longer pushed
down), and testing an alternative pushed-down case for the other
version.
It's not clear to me how to test that that
1062963-floatmanager-reflow.html still tests what it originally tested,
given the code change that's happened since.
--HG--
extra : commitid : 178ok0G1NFo
This adds an additional retry loop in block reflow that we can only
trigger when reflowing a block formatting context (replacedBlock
non-null). It can retry in two different ways, either with a narrower
width but at the same vertical position (when
ReplacedBlockFitsInAvailSpace is still true) or at a new vertical
position (which is treated as a form of clearance).
Fortunately we don't have to worry about margins collapsing *through*
such a boundary since we're dealing with a new block formatting context.
Note that Chromium passes all of the new bfc-displace-* tests, although
it moves the block formating context down unnecessarily in
bfc-shrink-1.html (which we do neither before nor after the patch),
though agrees with the width we have after the patch (but not before the
patch).
--HG--
extra : commitid : FgDc4hjTxHp
Without this change, nsBlockFrame::ReflowBlockFrame will fail to have
mayNeedRetry true, which means that it won't set
blockHTMLRS.mDiscoveredClearance, which means that on a descendant
replaced block we will fail to fall into any of the cases that call
ClearFloats. This change will cause us to hit the first ClearFloats
call and discover the need for clearance.
I tested locally that the new reftest fails without the patch and passes
with the patch.
* * *
Bug 1131451 part 2a - Remove hack for rtl-in-vertical-mode from ReflowAbsoluteFrame. r=dholbert
* * *
Bug 1131451 part 2b - Mark relative-overconstrained tests that now pass in vertical mode with rtl. r=dholbert
* * *
Bug 1131451 part 2c - Mark vertical border-collapse bevel tests that now pass. r=dholbert
* * *
Bug 1131451 part 2d - Remove partial rtl-in-vertical support from nsBidiPresUtils now that logical-coordinate classes handle it better. r=dholbert
* * *
Bug 1131451 part 2e - Remove hack for float positioning in vertical mode with dir=rtl. r=dholbert
* * *
Bug 1131451 part 2f - Mark vertical-mode float-in-rtl reftests that are now passing. r=dholbert
* * *
Bug 1131451 part 2g - Compute both dimensions of containerSize in nsFlexContainerFrame::DoLayout. r=dholbert
* * *
Bug 1131451 part 2h - Mark flexbox writing-mode tests that are now passing. r=dholbert
Outer table frames act as CSS2.1 table wrapper boxes. We used to lay them out
without taking their margins into the account, which meant that their width was
always equal to the available width. This breaks horizontal positioning of
absolutely positioned kids of a table frame.
The main purpose of this patch is to apply the margins of tables to their outer
frame, instead of the inner frame. This means that the inner table frame will
always have a zero margin, which means that a lot of the stuff which used to
rely on the fact that table margins are applied to the inner frame need to
change.
In particular, in order to get the computed margins of a table, we used to query
the inner table frame, and this patch corrects that. Also, when shrink wrapping
tables, we used to not take the margins of the inner table frame into account,
which is fixed by this patch too. nsBlockReflowState::
ComputeReplacedBlockOffsetsForFloats also needed to be changed to read the
margin values from the outer frame too.
Also, as part of this patch, we start to respect the CSS2.1 margin model for
captions on all sides. This means that in particular, the top/bottom margins on
the top-outside and bottom-outside captions will not be collapsed with the
top/bottom margins of the table, and that the margins of the caption element
contribute to the width and height of the outer table frame. The
427129-table-caption reftest has been modified to match this new behavior.
Another side effect of this bug is fixing bug 87277, and the reftests for that
bug are marked as passing in this patch.
Shing Lyu
Xidorn Quan
Mason Chang
Ting-Yu Lin
L. David Baron
Manish Goregaokar
Phil Ringnalda
Jonathan Kew
Andrew Comminos
Simon Montagu
Ryan VanderMeulen
Wes Kocher
CJKu
Vincent Chen
Corey Ford
Ehsan Akhgari