This change will allow the border drawing code to deal with the following
changes, which will make us no longer force the fieldset to be wider than the
legend. Without this patch, allowing the fieldset to be narrower than the
legend causes the vertical inline-start-side and inline-end-side borders of the
fieldset to paint under the legend, because the current code only modifies the
painting of the block-start-side border (the one the legend is positioned on).
This does change behavior in one situation, which the new tests test. For
relatively positioned legends, we used to use the original vertical location but
the positioned horizontal location of the legend to decide which parts of the
border to not paint. In the new setup, we use the original location for both.
I did check that this new behavior matches Chrome and Safari. Edge seems to
have our old behavior.
This change will allow the border drawing code to deal with the following
changes, which will make us no longer force the fieldset to be wider than the
legend. Without this patch, allowing the fieldset to be narrower than the
legend causes the vertical inline-start-side and inline-end-side borders of the
fieldset to paint under the legend, because the current code only modifies the
painting of the block-start-side border (the one the legend is positioned on).
This does change behavior in one situation, which the new tests test. For
relatively positioned legends, we used to use the original vertical location but
the positioned horizontal location of the legend to decide which parts of the
border to not paint. In the new setup, we use the original location for both.
I did check that this new behavior matches Chrome and Safari. Edge seems to
have our old behavior.
This patch was generated by the command:
find . -name "*.css" -exec sed -i -f mozpropsub {} \;
in the root of a mozilla-central tree, with the file mozpropsub
containing the contents:
s/-moz-padding-end\>/padding-inline-end/g
s/-moz-padding-start\>/padding-inline-start/g
s/-moz-margin-end\>/margin-inline-end/g
s/-moz-margin-start\>/margin-inline-start/g
s/-moz-border-end\>/border-inline-end/g
s/-moz-border-end-color\>/border-inline-end-color/g
s/-moz-border-end-style\>/border-inline-end-style/g
s/-moz-border-end-width\>/border-inline-end-width/g
s/-moz-border-start\>/border-inline-start/g
s/-moz-border-start-color\>/border-inline-start-color/g
s/-moz-border-start-style\>/border-inline-start-style/g
s/-moz-border-start-width\>/border-inline-start-width/g
While I didn't manually review all the changes, I did review the list of
files, and manually reviewed the changes in the files that I thought
were more interesting.
Note that there are a few tests that should be fixed up as well, but
I'll do that in a later patch.
MozReview-Commit-ID: EiQTuuV0MNQ
Make the test_transformed_scrolling_repaints* tests taller so that the top and the bottom of the scrolled area don't share the same tile.
Fuzz layout/reftests/text/wordwrap-03.html on Linux because the native textbox gradient is painted in a slightly different position depending on the invalid area.
Mark layout/reftests/forms/select/out-of-bounds-selectedindex.html as fuzzy on Android because some listbox rounded corner pixel differs with the new invalidation behavior.
Mark layout/reftests/bugs/456219-1c.html as fuzzy on Linux, reasons unknown. :-(
Disable flexbox-widget-flex-items-3.html because of bad file input drawing on Linux, see bug 1260965.
MozReview-Commit-ID: B5c1a8D0G8F
--HG--
extra : rebase_source : 3e281d035831c77246d0e439246fdab9395dc884
Update the fuzz test for reftest placeholder-6.html to allow a single pixel to be
off by one in Fennec when C++APZ is enabled.
--HG--
extra : commitid : xWf4FNDIQr
With APZ, we always layerize the first scrollable element of the page,
if the page itself is not scrollable. These additional layers can cause
fuzzy reftest failures in two ways: differences in blending, and by
disabling sub-pixel test anti-aliasing. The latter is only a problem
with unaccelerated drawing, because we don't support component alpha
layers with BasicLayers. (We also don't support them with
BasicCompositor, but "Reftest unaccelerated" only tests BasicLayers).
Note that this replaces the code that allows eroding the space with new
code that reduces the focusPadding value.
(Also, we previously didn't count the focusPadding towards what could be
eroded, which meant we wouldn't quite get to the edge of the padding and
border, because we weren't counting the extra for the focusPadding.)
The existing reftests that I'm changing from == to != are ones that were
specifically testing issues related to erosion of padding.
The change to 491180-{1,2}-ref.html is because we now *do* erode the
focusPadding, which is 3px in the horizontal dimensions (see the
button::-moz-focus-inner styles in forms.css), and that was the only
nonzero style on the button in 491180-{1,2}.html.
CLOSED TREE (per RyanVM)
Note that this replaces the code that allows eroding the space with new
code that reduces the focusPadding value.
(Also, we previously didn't count the focusPadding towards what could be
eroded, which meant we wouldn't quite get to the edge of the padding and
border, because we weren't counting the extra for the focusPadding.)
The existing reftests that I'm changing from == to != are ones that were
specifically testing issues related to erosion of padding.
The change to 491180-{1,2}-ref.html is because we now *do* erode the
focusPadding, which is 3px in the horizontal dimensions (see the
button::-moz-focus-inner styles in forms.css), and that was the only
nonzero style on the button in 491180-{1,2}.html.
Note that this replaces the code that allows eroding the space with new
code that reduces the focusPadding value.
(Also, we previously didn't count the focusPadding towards what could be
eroded, which meant we wouldn't quite get to the edge of the padding and
border, because we weren't counting the extra for the focusPadding.)
The existing reftests that I'm changing from == to != are ones that were
specifically testing issues related to erosion of padding.
The change to 491180-{1,2}-ref.html is because we now *do* erode the
focusPadding, which is 3px in the horizontal dimensions (see the
button::-moz-focus-inner styles in forms.css), and that was the only
nonzero style on the button in 491180-{1,2}.html.