Tons of new passes, some fuzzy bits, and one failure from a test that makes bad
assumptions about themed and unthemed <input type=color> being equally tall.
Differential Revision: https://phabricator.services.mozilla.com/D65724
--HG--
extra : moz-landing-system : lando
A similar reasoning as in bug 1540176 applies here as well: Pending a possible
rework of the AutoMaybeDisableFontInflation logic (bug 1619749), inflation
containers generally cannot take the (I)size increase of font inflation into
account during shrink-wrapping, and form controls like buttons are particularly
hard hit, as
a) they often contain only small amounts of text and
b) unlike regular "inline-block" elements such as <div>s, they aren't font
inflation flow roots either, and as such are therefore subject to the full
amount of font inflation from their surrounding contents,
so they are more likely to end up with a situation were the inflated text won't
fit the ISize of the button even with word wrapping applied.
Therefore, as a quicker fix, buttons will now also specifically prevented from
becoming font inflation containers.
This also has the added advantage that they thereby become subject to the logic
from bug 708175 - i.e. if the button has a fixed width, we will no now no longer
inflate its text.
Differential Revision: https://phabricator.services.mozilla.com/D66097
--HG--
extra : moz-landing-system : lando
Buttons with a fixed height are already correctly prevented from inflating, so
their test already passes. Everything else will be done subsequently.
Differential Revision: https://phabricator.services.mozilla.com/D66096
--HG--
extra : moz-landing-system : lando
It seems webrender has some invalidation issues on the test reference and won't
paint the selected text on time. Instead, run the selection ASAP so that it
hopefully paints soon enough.
Differential Revision: https://phabricator.services.mozilla.com/D66108
--HG--
extra : moz-landing-system : lando
Otherwise the rendering of stuff like:
<input type=range style="height: 300px">
Makes no sense. So this is closer to other widgets, and also happens to fix the
only test which is a real regression from non-native widget :)
Depends on D65673
Differential Revision: https://phabricator.services.mozilla.com/D65674
--HG--
extra : moz-landing-system : lando
Most of them are straight-forward. Some fuzziness due to Skia around rounded
corners still. Some tests that already fail in other widgets as expected.
This is enough to green up reftests (but not WPT, yet) on Android, both with and
without WR enabled.
Nothing too concerning, all-in-all.
Differential Revision: https://phabricator.services.mozilla.com/D65667
--HG--
extra : moz-landing-system : lando
The test is duplicated in two places, so four files to change. The padding in
the non-native theme is just big enough so that the textarea overlaps the float.
In other themes the textarea overflows, but not enough to hit the float.
Differential Revision: https://phabricator.services.mozilla.com/D65663
--HG--
extra : moz-landing-system : lando
...and properly pixel-snap while at it, as otherwise my test would fail fuzzily.
Stroke() paints a stroke from the middle of the path, so it'll paint
one-half-of-the-width outside of the rect.
We need to deflate it by half the border width so that the stroke covers exactly
the area we want.
Differential Revision: https://phabricator.services.mozilla.com/D65422
--HG--
extra : moz-landing-system : lando
Previously, text input controls weren't font inflation containers simply by
virtue of being "display:inline" by default, which automatically makes them in-
eligible for becoming an inflation container.
As of bug 1539469 this has changed however - those <input> elements are now
"display:inline-block" by default, which with the current font inflation logic
turns them into font inflation containers.
This leads to a few problems:
1. The logic from bug 708175 (stop inflation if there is a size-constrained non-
inline frame in the chain from the current frame to their font inflation
container) is built on the assumption that the (possibly size-constrained)
form control itself isn't a font inflation container.
2. When form controls end up as font inflation containers themselves, they no
longer size themselves properly to match the size of their inflated
contents, because they are now subject to the AutoMaybeDisableFontInflation/
mInflationDisabledForShrinkWrap logic which ends up disabling font inflation
during the size calculation of the form control.
1.) means that we now inflate some text inputs that we didn't use to inflate
previously and 2.) means that every time we attempt to inflate a text input, we
end up with the text content being inflated, but the containig box being not and
therefore too small.
Because of this, as well as because
1. The introductory comment in nsFrame::IsFontSizeInflationContainer itself
mentions that form controls aren't expected to be inflation containers.
2. There is the precedent from bug 786946, where <select> elements were
specifically excluded from becoming font inflation containers when their
default display style was changed from "inline" to "inline-block".
all of this points towards having to specifically preclude <input> elements
from becoming font inflation containers as well.
Differential Revision: https://phabricator.services.mozilla.com/D64908
--HG--
extra : moz-landing-system : lando
Reuse the AddXULMinSize logic which already deals with all the widget stuff,
non-themed scrollbars, etc.
Remove some useless margin declarations and such in GeckoView scrollbars code
now that AddXULMinSize does look at the min-width/height properties.
Differential Revision: https://phabricator.services.mozilla.com/D65129
--HG--
extra : moz-landing-system : lando
Maybe we should be using some native color, but the background for that is white
in my testing, so probably not, or at least probably it can be a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D64816
--HG--
extra : moz-landing-system : lando
The last css suite (css-writing-modes) is removed in Part 1. We can
remove the infrastructure.
Differential Revision: https://phabricator.services.mozilla.com/D62985
--HG--
extra : moz-landing-system : lando
See bug 1598754 comment 1 for an analysis and observation after aligning
the pass/fail state with wpt.
This patch is generated by
1. removing `os.path.join("css-writing-modes"),` in import-tests.py.
2. removing the relevent annotations of css-writing-modes in failures.list.
3. running import-tests.py on a wpt repository at commit
15f199c91a72b0d51bf0a12b3b77827ecb5051ff.
Differential Revision: https://phabricator.services.mozilla.com/D62984
--HG--
extra : moz-landing-system : lando
Sometimes the painting code will look at the clip which is derived
from the intial size of the surface and not draw if things if they
are outside of it. We want to draw the entire item so use dtRect
instead of visibleRect.
Differential Revision: https://phabricator.services.mozilla.com/D64277
--HG--
extra : moz-landing-system : lando
In order for the test to pass the scroll event handler needs to run so that a scroll linked effect is detected and apz is disabled. It is triggered by the scrollTo call in the load handler. Which then removes reftest-wait off a setTimeout(..., 0). The scroll event is dispatched from the refresh driver so it can happen after this setTimeout runs. So the scroll handler runs too late to affect the test.
Differential Revision: https://phabricator.services.mozilla.com/D62387
--HG--
extra : moz-landing-system : lando
With the new 'defaults' key being added, 'default-preferences' is now
redundant. This commit converts all existing uses of 'default-preferences' to
use 'defaults' instead.
Differential Revision: https://phabricator.services.mozilla.com/D63247
--HG--
extra : moz-landing-system : lando
This introduces a new 'defaults' key to reftest manifests. It works similarly
to the existing 'default-preferences' key except it can be used for any test
modifier (e.g, skip-if, fail-if, pref, etc.).
See the changes to README.txt in this commit for an explanation on how to use
it.
Differential Revision: https://phabricator.services.mozilla.com/D63246
--HG--
extra : moz-landing-system : lando
So that we can generate nsImageFrame for lazy load image elements in the first
place.
Differential Revision: https://phabricator.services.mozilla.com/D61942
--HG--
rename : layout/reftests/image/moz-broken-matching-1.html => layout/reftests/image/moz-broken-matching-lazy-load.html
extra : moz-landing-system : lando
This is done using a similar approach to CreateWebRenderCommands
but slightly modified. In particular the active layer check needs
to be done before we're ready to CreateWebRenderCommands, but once
we decide to activate an item, we can't let CreateWebRenderCommands
fail. Unfortunately, the need to query ImageLib for support means
we need to do basically ~all of the work of CreateWebRenderCommands
to do this check.
As such, this introduces a modified version of CreateWebRenderCommands
that SVGGeometryFrames implement with a "dry run" flag. When true,
it runs the same code but stops short of mutating the WR DL/state.
ImageLib may be encouraged to do some extra work that could be thrown
away, but I'm not sure there's any way to avoid that.
For now, only SVGImageFrame actually provides an implementation. The
bulk of the implementation is handling the on-by-default
preserveAspectRatio feature of SVG images. It was cleaner to just
reimplement that logic than reuse the existing preserveAspectRatio
code, as it was too tangled up in the particulars of how the PaintSVG
path is designed.
Differential Revision: https://phabricator.services.mozilla.com/D59925
--HG--
extra : moz-landing-system : lando
This is done using a similar approach to CreateWebRenderCommands
but slightly modified. In particular the active layer check needs
to be done before we're ready to CreateWebRenderCommands, but once
we decide to activate an item, we can't let CreateWebRenderCommands
fail. Unfortunately, the need to query ImageLib for support means
we need to do basically ~all of the work of CreateWebRenderCommands
to do this check.
As such, this introduces a modified version of CreateWebRenderCommands
that SVGGeometryFrames implement with a "dry run" flag. When true,
it runs the same code but stops short of mutating the WR DL/state.
ImageLib may be encouraged to do some extra work that could be thrown
away, but I'm not sure there's any way to avoid that.
For now, only SVGImageFrame actually provides an implementation. The
bulk of the implementation is handling the on-by-default
preserveAspectRatio feature of SVG images. It was cleaner to just
reimplement that logic than reuse the existing preserveAspectRatio
code, as it was too tangled up in the particulars of how the PaintSVG
path is designed.
Differential Revision: https://phabricator.services.mozilla.com/D59925
--HG--
extra : moz-landing-system : lando
The existing code just clipped to a rect. We need to do the same clipping that the non-remote code path does which also handles border radius.
The existing code is the from initial implementation of nsDisplayRemote in https://hg.mozilla.org/mozilla-central/rev/85d06279c8358a8e1c883aa670a20212b1039a90 so I suspect that clipping to the inner view bounds instead of the frame content box is not an important difference.
Differential Revision: https://phabricator.services.mozilla.com/D62180
--HG--
extra : moz-landing-system : lando
For Draw (non-native) and CA modes, we include the per-tile
valid rect in the clip rect from the surface.
For DC (non-virtual) mode, a per-tile clip rect is set on the
visual for each tile, separate from the overall clip rect that
is set on the surface visual.
For DC (virtual) mode, the Trim API is used to remove pixels
in the virtual tile area that are outside the valid / clipped
region.
Note: Although the valid rect is now applied in the native
compositors, it's currently only based on the overall picture
cache bounding rect. Thus, with this patch there isn't any
noticeable performance improvement. Once this lands and is
working correctly, the follow up patch to calculate a smaller
valid region per-tile is a small amount of work.
Differential Revision: https://phabricator.services.mozilla.com/D61424
--HG--
extra : moz-landing-system : lando
I think this probably only shows up with fission oop iframes, tabs probably avoid this path.
The problem occurs when we reconstruct the containing iframe for a style change, we briefly hide the child document, clearing the display list on the parent via ClearCachedResources. Then show it again, we attempt an empty transaction and this succeeds because there is nothing to stop it. (The non-wr case fails because the layer contents are missing and that causes the empty transaction to fail.)
So keep track if we have sent a display list to the parent to allow/disallow an empty transaction.
This fixes a couple webrender+fission reftest failures but it's also a general rendering bug in webrender+fission reproducible in a regular browser.
Differential Revision: https://phabricator.services.mozilla.com/D61577
--HG--
extra : moz-landing-system : lando
See bug 1598753 comment 1 for the analysis.
This patch is generated by
1. removing `os.path.join("css-values"),` in import-tests.py
2. removing the relevent annotations of css-values
3. running import-tests.py on a wpt repository at commit
15f199c91a72b0d51bf0a12b3b77827ecb5051ff.
Differential Revision: https://phabricator.services.mozilla.com/D62142
--HG--
extra : moz-landing-system : lando
There were two issues with the existing code that we use to determine whether a
widget is styled or not.
First, it was using `color == Color::transparent()` instead of
`color.is_transparent()` to check for transparent backgrounds. That is not sound
as `Color::transparent()` is the literal value `rgba(0, 0, 0, 0)`, not the
`transparent` keyword, so the equality check would fail.
The other issue is that this function was early-returning false if that check
was returning false. It is a bug for this function to early-return false, as it
makes the result of the function dependent of the order of the declarations.
Differential Revision: https://phabricator.services.mozilla.com/D62060
--HG--
extra : moz-landing-system : lando
Use MozReftestInvalidate rather than onload, following the pattern of most of
the tests in layout/reftests/selection.
Differential Revision: https://phabricator.services.mozilla.com/D62139
--HG--
extra : moz-landing-system : lando
Add a reftest that would fail in webrender before the corresponding
fix landed.
Ensures that there is an async zoom and that both the layout and
visual viewports have async scroll offsets. To pass, we must apply
each of the layout and visual offsets in their correct coordinate
spaces.
Differential Revision: https://phabricator.services.mozilla.com/D61788
--HG--
extra : moz-landing-system : lando
Add a reftest that would fail in webrender before the corresponding
fix landed.
Ensures that there is an async zoom and that both the layout and
visual viewports have async scroll offsets. To pass, we must apply
each of the layout and visual offsets in their correct coordinate
spaces.
Differential Revision: https://phabricator.services.mozilla.com/D61788
--HG--
extra : moz-landing-system : lando
Annotate optiontext.html for Android as slightly fuzzy, to account for
reftest rebucketing fuzzy-failure fallout. It has 0 in the lower bound
of the fuzzy annotation because not every Android has this
fuzzy-failure.
Meanwhile, bug453105.html no longer fails due to reftest rebucketing, so
I remove its fuzzy annotation.
Differential Revision: https://phabricator.services.mozilla.com/D61877
--HG--
extra : moz-landing-system : lando
No test in css-conditional reftests are failures, which matches
testing/web-platform/meta/css/css-conditional.
This patch is generated by
1. manually removing `os.path.join("css-conditional"),` in import-tests.py, and
2. running import-tests.py on a wpt repository at commit
15f199c91a72b0d51bf0a12b3b77827ecb5051ff.
Differential Revision: https://phabricator.services.mozilla.com/D61594
--HG--
extra : moz-landing-system : lando
We replace SetWidthIfLength and SetOffsetIfLength with ComputeDecorationLine{Thickness,Offset} functions,
and consolidate more of the computation of the offset within this function to simplify callers.
Differential Revision: https://phabricator.services.mozilla.com/D61454
--HG--
extra : moz-landing-system : lando
We're resetting `color` to the default color when there's a declaration that
applies in order to make stuff like this:
<div style="color: transparent">
<div style="color: red">
Red
</div>
</div>
To not show transparent. But the behavior we want is more like "override with
default color iff there's no other declaration that would set the color from an
user or UA sheet".
This implements that behavior, plus avoids it if we're not inheriting
from transparent, so that stuff like this preserves the behavior from before bug
844349:
<a href="foo">
<span style="color: red">Should be the red color</span>
</a>
Differential Revision: https://phabricator.services.mozilla.com/D60391
--HG--
extra : moz-landing-system : lando
We're resetting `color` to the default color when there's a declaration that
applies in order to make stuff like this:
<div style="color: transparent">
<div style="color: red">
Red
</div>
</div>
To not show transparent. But the behavior we want is more like "override with
default color iff there's no other declaration that would set the color from an
user or UA sheet".
This implements that behavior, plus avoids it if we're not inheriting
from transparent, so that stuff like this preserves the behavior from before bug
844349:
<a href="foo">
<span style="color: red">Should be the red color</span>
</a>
Differential Revision: https://phabricator.services.mozilla.com/D60391
--HG--
extra : moz-landing-system : lando
This test also has the same dashed border and occasional fuzziness
that grid-track-intrinsic-sizing-003.html does with DC enabled.
Differential Revision: https://phabricator.services.mozilla.com/D60947
--HG--
extra : moz-landing-system : lando
The gradient code is the only one that does a really weird thing with
LengthPercentage values, by getting the percentage and length separately and
turning the length into a percentage relative to the line length (which is in
device pixels).
This won't work once we have min() / max() / etc. in CSS (as we can't access
the length and percentage components separately, as which one you choose may
depend on the percentage basis). So instead of that, use the regular
ResolveToCssPixels there are lengths involved.
We change a bit the surrounding code to work in CSS pixels, so as to avoid
unneeded CSS -> device pixel conversions.
Differential Revision: https://phabricator.services.mozilla.com/D60159
--HG--
extra : moz-landing-system : lando
This patch adds fuzziness for three tests that have intermittent
fuzziness issues when DirectComposition virtual surfaces are enabled.
In each of the cases, there is a dashed border style, which has
occasional rasterizer accuracy issues. Each of the tests has a
max fuzziness of 0-1 value, with 0-10 pixels, so it's a minimal
amount of difference between the images.
Given this, we can add fuzziness to allow enabling the native
compositor mode, and investigate these as follow ups.
Differential Revision: https://phabricator.services.mozilla.com/D60788
--HG--
extra : moz-landing-system : lando
The gradient code is the only one that does a really weird thing with
LengthPercentage values, by getting the percentage and length separately and
turning the length into a percentage relative to the line length (which is in
device pixels).
This won't work once we have min() / max() / etc. in CSS (as we can't access
the length and percentage components separately, as which one you choose may
depend on the percentage basis). So instead of that, use the regular
ResolveToCssPixels there are lengths involved.
We change a bit the surrounding code to work in CSS pixels, so as to avoid
unneeded CSS -> device pixel conversions.
Differential Revision: https://phabricator.services.mozilla.com/D60159
--HG--
extra : moz-landing-system : lando
There are a number of issues with the current gradient dithering
implementation, that cause many test failures and also fuzziness
rendering when enabling DirectComposition virtual surfaces. In
particular, the dither result is dependent on the offset of the
update rect within a render target.
For now, this patch disables gradient dithering by default. This
gives us:
- A heap of new test PASS results (or reduced fuzziness).
- Fixes a number of non-deterministic fuzziness bugs with DC.
- Improves performance of gradient rendering by a reasonable amount.
We can fix gradient dithering as a follow up, and re-enable if/when
we find content that would benefit from it significantly (we may
be able to improve gradients in other ways than dithering too).
Differential Revision: https://phabricator.services.mozilla.com/D60460
--HG--
extra : moz-landing-system : lando
Changes:
After a lot of hours spent tweaking the exact values for this test, the conclusion is that it is flaky. Sometimes it passes with 0,0 but other times it fails with 255,66 only for linux webrender.
Differential Revision: https://phabricator.services.mozilla.com/D60466
--HG--
extra : moz-landing-system : lando
Changes:
Tighten reftest pixel differences now that reftest has been migrated fully over to ubuntu1804.
Differential Revision: https://phabricator.services.mozilla.com/D59597
--HG--
extra : moz-landing-system : lando
Changes:
Tighten reftest pixel differences now that reftest has been migrated fully over to ubuntu1804.
Differential Revision: https://phabricator.services.mozilla.com/D59595
--HG--
extra : moz-landing-system : lando
Changes:
Tighten reftest pixel differences now that reftest has been migrated fully over to ubuntu1804.
Differential Revision: https://phabricator.services.mozilla.com/D59594
--HG--
extra : moz-landing-system : lando
layout/reftests/bugs/262998-1.html only fails with webrender. I think maybe the initial annotation should have had that.
layout/reftests/bugs/818276-1.html I think is the same situation.
layout/reftests/474472-1.html seems to pass on a no-accel reftest fis run, but fails for me on regular reftest fis run, so I marked it random for now.
Differential Revision: https://phabricator.services.mozilla.com/D60105
--HG--
extra : moz-landing-system : lando
Now that we're subclassing nsTextControlFrame we can use the regular replaced
element intrinsic sizing, rather than just faking it in the UA sheet with a
suspicious width declaration.
Differential Revision: https://phabricator.services.mozilla.com/D59981
--HG--
extra : moz-landing-system : lando
Now that we're subclassing nsTextControlFrame we can use the regular replaced
element intrinsic sizing, rather than just faking it in the UA sheet with a
suspicious width declaration.
Differential Revision: https://phabricator.services.mozilla.com/D59981
--HG--
extra : moz-landing-system : lando
Changes:
Tighten reftest pixel differences now that reftest has been migrated fully over to ubuntu1804.
Differential Revision: https://phabricator.services.mozilla.com/D59598
--HG--
extra : moz-landing-system : lando
Instead, subclass nsTextControlFrame. This simplifies the code and avoids
correctness issues.
I kept the localization functionality though it is not spec compliant. But I
filed a bug to remove it in a followup.
Differential Revision: https://phabricator.services.mozilla.com/D57193
--HG--
extra : moz-landing-system : lando
PDFJS uses it, for example to allow text selection. It's not great if it shows
on top of the actual PDF :-)
Differential Revision: https://phabricator.services.mozilla.com/D58703
--HG--
extra : moz-landing-system : lando
Instead, subclass nsTextControlFrame. This simplifies the code and avoids
correctness issues.
I kept the localization functionality though it is not spec compliant. But I
filed a bug to remove it in a followup.
Differential Revision: https://phabricator.services.mozilla.com/D57193
--HG--
extra : moz-landing-system : lando
Do this only on nightly for now since we're about to enter the soft freeze.
(No test updates yet, as try is still running, and I need to figure out how to
import Oriol's changes into WPT, but I wanted to ensure that you were fine with
this)
Differential Revision: https://phabricator.services.mozilla.com/D54595
--HG--
extra : moz-landing-system : lando
Do this only on nightly for now since we're about to enter the soft freeze.
(No test updates yet, as try is still running, and I need to figure out how to
import Oriol's changes into WPT, but I wanted to ensure that you were fine with
this)
Differential Revision: https://phabricator.services.mozilla.com/D54595
--HG--
extra : moz-landing-system : lando
This test is proving to be a nuisance during the migration.
Temporarily disable it while the reftest-no-accel suite is greened up on ubuntu1804 and ready for migration on mozilla-central.
Differential Revision: https://phabricator.services.mozilla.com/D59384
--HG--
extra : moz-landing-system : lando
Changes:
Remove the fail-if annotation for gtkWidget since the test passes in ubuntu1804.
This patch will need to land with D58816.
Differential Revision: https://phabricator.services.mozilla.com/D54851
--HG--
extra : moz-landing-system : lando
Simply remove "max-block-size: 100%" for -moz-column-set and
-moz-column-content breaks abspos-breaking-dynamic-{001,002,003}.html.
We need to reflow ColumnSetWrapper's children whenever
ColumnSetWrapper's block-size or max-block-size is changed because both
size affect the available block-size for ColumnSetWrapper's children.
We set `NS_FRAME_CONTAINS_RELATIVE_BSIZE` for ColumnSetWrapperFrame so
that it will set itself dirty in `selfDirty` in
`nsBlockFrame::ReflowDirtyLines`, and mark its lines dirty if
`aState.mReflowInput.IsBResize()` is true.
Differential Revision: https://phabricator.services.mozilla.com/D58731
--HG--
extra : moz-landing-system : lando
It is unexpected (see bug) that a -moz-box is affected by baseline alignment.
Make -moz-box be block-outside, and -moz-inline-box be inline-outside, instead
of the bespoke thing we have now.
This is more similar to everything else, and fixes the bug.
Differential Revision: https://phabricator.services.mozilla.com/D58726
--HG--
extra : moz-landing-system : lando
Simply remove "max-block-size: 100%" for -moz-column-set and
-moz-column-content breaks abspos-breaking-dynamic-{001,002,003}.html.
We need to reflow ColumnSetWrapper's children whenever
ColumnSetWrapper's block-size or max-block-size is changed because both
size affect the available block-size for ColumnSetWrapper's children.
We set `NS_FRAME_CONTAINS_RELATIVE_BSIZE` for ColumnSetWrapperFrame so
that it will set itself dirty in `selfDirty` in
`nsBlockFrame::ReflowDirtyLines`, and mark its lines dirty if
`aState.mReflowInput.IsBResize()` is true.
Differential Revision: https://phabricator.services.mozilla.com/D58731
--HG--
extra : moz-landing-system : lando
It is unexpected (see bug) that a -moz-box is affected by baseline alignment.
Make -moz-box be block-outside, and -moz-inline-box be inline-outside, instead
of the bespoke thing we have now.
This is more similar to everything else, and fixes the bug.
Differential Revision: https://phabricator.services.mozilla.com/D58726
--HG--
extra : moz-landing-system : lando
Add some SCHEDULES rules so that, when a push only modifies files known to be associated
with a particular test suite, only that test suite is run.
Differential Revision: https://phabricator.services.mozilla.com/D58448
--HG--
extra : moz-landing-system : lando
Changes:
`gtkWidget&&webrender` has a slightly different pixel difference count (1496 vs 1498), so a second condition is added to cover this case.
The annotation is permissive but will be tightened once reftest is run with ubuntu1804.
Differential Revision: https://phabricator.services.mozilla.com/D58862
--HG--
extra : moz-landing-system : lando
Changes:
Remove the fail-if annotation for gtkWidget since the test passes in ubuntu1804.
This patch will need to land with D58816.
Differential Revision: https://phabricator.services.mozilla.com/D54851
--HG--
extra : moz-landing-system : lando
Changes:
Mark with permissive fuzzy-if annotation, to permit both ubuntu1604 and ubuntu1804 to pass for the time being.
Test will have annotation tightened up once migration is complete.
Differential Revision: https://phabricator.services.mozilla.com/D58405
--HG--
extra : moz-landing-system : lando
bug 1598755 comment 1 contains an analysis to align wpt's test results
with our own reftest framework, so it is ok to remove these reftests.
In this patch, the manual modifications are
1. removing `os.path.join("selector"),` in import-tests.py, and
2. removing relevant annotations in failures.list.
Others parts are generated by running import-tests.py on a wpt
repository with commit 15f199c91a72b0d51bf0a12b3b77827ecb5051ff.
Depends on D58023
Differential Revision: https://phabricator.services.mozilla.com/D58024
--HG--
extra : moz-landing-system : lando
Changes:
Mark this particular failure with permissive fuzzy-if to be investigated at a later time. In the meantime this will permit both ubuntu16/18 to pass the tests.
Differential Revision: https://phabricator.services.mozilla.com/D57753
--HG--
extra : moz-landing-system : lando
Changes:
Marking the test with a permissive `fuzzy-if` to accommodate both ubuntu1804 and ubuntu1604; fuzzy value will be tightened once migration is complete.
Differential Revision: https://phabricator.services.mozilla.com/D57728
--HG--
extra : moz-landing-system : lando
Changes:
Most tests have smaller value for the `minDiff` side of things, and a slightly larger value for the `maxPixelCount` side of things when ubunt1804 runs the test. Adjust the expectation so that ubuntu1604 and ubuntu1804 both pass for the time being, then tighten the values once ubuntu1604 is decommissioned.
Differential Revision: https://phabricator.services.mozilla.com/D57560
--HG--
extra : moz-landing-system : lando
Changes:
As with other ubuntu1804 reftests, the difference counts need to be updated when run with `webrender`. Once migration is complete, tighten the values.
Differential Revision: https://phabricator.services.mozilla.com/D57604
--HG--
extra : moz-landing-system : lando