This patch was written entirely by the following script:
#!/bin/bash
if [ ! -d "./.hg" ]
then
echo "Not in a source tree." 1>&2
exit 1
fi
find . -regex '.*\(ref\|crash\)test.*\.list' | while read FILENAME
do
echo "Processing ${FILENAME}."
# The following has four substitutions:
# * The first one replaces the *first* argument to fuzzy() when it doesn't
# have a - in it, by replacing it with an explicit 0-N range.
# * The second one does the same for the *second* argument to fuzzy().
# * The third does the same for the *second* argument to fuzzy-if().
# * The fourth does the same for the *third* argument to fuzzy-if().
#
# Note that this is using perl rather than sed because perl doesn't
# support non-greedy matching, which is needed for the first argument to
# fuzzy-if.
perl -pi -e 's/(fuzzy\()([^ ,()-]*)(,[^ ,()]*\))/${1}0-${2}${3}/g;s/(fuzzy\([^ ,()]*,)([^ ,()-]*)(\))/${1}0-${2}${3}/g;s/(fuzzy-if\([^ ]*?,)([^ ,()-]*)(,[^ ,()]*\))/${1}0-${2}${3}/g;s/(fuzzy-if\([^ ]*?,[^ ,()]*,)([^ ,()-]*)(\))/${1}0-${2}${3}/g' "${FILENAME}"
done
Differential Revision: https://phabricator.services.mozilla.com/D2974
--HG--
extra : moz-landing-system : lando
The ceiling was introduced in bug 549190 for improve the consistency of
underline positioning. However, removing ceiling now doesn't seem to
regress the testcases in that bug, probably thanks to improvement in
other part.
The ceiling here causes us to have different font metrics than other
browsers on Windows, and can lead to webcompat issue. We also don't do
this for other backends. So it's probably better removing it in favor
of rounding.
There are several test changes:
* min-intrinsic-with-percents-across-elements.html changes result due to
height of wrapping div in reference page depends on line height, so a
fixed line height is set to work around the issue.
* 368020-1.html changes result because a slightly different line-height
triggers bug 1462514. It is changed to use fixed line-height to work
around the issue.
* 456147.xul is disabled because it compares XUL against HTML page, but
XUL has different approach to position text in its elements than HTML.
Specifically, XUL elements don't seem to respect line height while
HTML elements do. The original line height in the file was probably
chosen to make the HTML match XUL, so it seems to be non-trivial to
fix it in a platform-independent way.
* sizing-orthog-{vlr,vrl}-in-htb-{008,020}.xht fails due to text in <p>
after the testing block shifts 1px up for unknown reason.
MozReview-Commit-ID: 2WJG1AigWl1
--HG--
extra : source : 653c6b7480997c4e1dbead5f0441bc06a0605b7a
The ceiling was introduced in bug 549190 for improve the consistency of
underline positioning. However, removing ceiling now doesn't seem to
regress the testcases in that bug, probably thanks to improvement in
other part.
The ceiling here causes us to have different font metrics than other
browsers on Windows, and can lead to webcompat issue. We also don't do
this for other backends. So it's probably better removing it in favor
of rounding.
There are several test changes:
* min-intrinsic-with-percents-across-elements.html changes result due to
height of wrapping div in reference page depends on line height, so a
fixed line height is set to work around the issue.
* 368020-1.html changes result because a slightly different line-height
triggers bug 1462514. It is changed to use fixed line-height to work
around the issue.
* 456147.xul is disabled because it compares XUL against HTML page, but
XUL has different approach to position text in its elements than HTML.
Specifically, XUL elements don't seem to respect line height while
HTML elements do. The original line height in the file was probably
chosen to make the HTML match XUL, so it seems to be non-trivial to
fix it in a platform-independent way.
* sizing-orthog-{vlr,vrl}-in-htb-{008,020}.xht fails due to text in <p>
after the testing block shifts 1px up for unknown reason.
MozReview-Commit-ID: 2WJG1AigWl1
--HG--
extra : rebase_source : 540e68ffff618a6dc3c14b3702b2c042988061a3
The ceiling was introduced in bug 549190 for improve the consistency of
underline positioning. However, removing ceiling now doesn't seem to
regress the testcases in that bug, probably thanks to improvement in
other part.
The ceiling here causes us to have different font metrics than other
browsers on Windows, and can lead to webcompat issue. We also don't do
this for other backends. So it's probably better removing it in favor
of rounding.
There are several test changes:
* min-intrinsic-with-percents-across-elements.html changes result due to
height of wrapping div in reference page depends on line height, so a
fixed line height is set to work around the issue.
* 368020-1.html changes result because a slightly different line-height
triggers bug 1462514. It is changed to use fixed line-height to work
around the issue.
* 456147.xul is disabled because it compares XUL against HTML page, but
XUL has different approach to position text in its elements than HTML.
Specifically, XUL elements don't seem to respect line height while
HTML elements do. The original line height in the file was probably
chosen to make the HTML match XUL, so it seems to be non-trivial to
fix it in a platform-independent way.
* sizing-orthog-{vlr,vrl}-in-htb-{008,020}.xht fails due to text in <p>
after the testing block shifts 1px up for unknown reason.
MozReview-Commit-ID: 2WJG1AigWl1
--HG--
extra : rebase_source : 6c61fa95a3b01e7b439be46a2498b4f893d8b84b
Skip tests that are expected to fail in both Stylo and Gecko modes. They would unexpectedly "pass" in styloVsGecko mode when comparing the two failures, which is not a useful result.
MozReview-Commit-ID: 3mOpjU225Q1
--HG--
extra : rebase_source : 22bb5d4e3c5138ef832995eaf5716824f4707ffe
extra : source : d40fb20c9a49d0797c0eeae613a04912b12a28f7
Skip tests that are expected to fail in both Stylo and Gecko modes. They would unexpectedly "pass" in styloVsGecko mode when comparing the two failures, which is not a useful result.
MozReview-Commit-ID: 3mOpjU225Q1
--HG--
extra : rebase_source : 0c307639c3626af3b6b43e05d3ee73d08b3f47ce
Disable 461917-1.xhtml under dom/xul/crashtests/ because I cannot reproduce
it locally.
Annotate assert-if on some crashtests (bug 1370830). Other modifications are
all removal of fails-if.
MozReview-Commit-ID: 6Q2A5M5rOry
--HG--
extra : rebase_source : b282a919fcda6287fe2eaa6b139a11f2663ad578
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
