The "inactive" event for MediaStream does not exist in the spec. Instead we can
check that the `active` attribute is set to false synchronously after stopping
tracks. For completion, we do this on all MediaStreams in the test.
Differential Revision: https://phabricator.services.mozilla.com/D35664
--HG--
extra : moz-landing-system : lando
Add `SameObject` and `PutForwards=cssText` to style attribute.
It's ok to add SameObject directly because we always return the same
data member after creating.
Besides, there is no need to manually update cpp function to support
PutForwards, so this update should be fine.
Differential Revision: https://phabricator.services.mozilla.com/D35583
--HG--
extra : moz-landing-system : lando
Correctly handle clamping to 1 behavior of grayscale(),
invert(), opacity() and sepia().
Differential Revision: https://phabricator.services.mozilla.com/D35509
--HG--
extra : moz-landing-system : lando
This test is known intermittent on windows. It's already annotated to be
disabled for some categories of Windows testers, but that annotation was overly
specific.
I've already fixed the "upstream" version of this test (the version in
layout/reftests), so the intermittent failure will stop once that fix has been
synchronized around. But in the meantime, let's adjust the annotation so that
it includes Win10 64-bit testers, so we don't get intermittent failures for
those testers.
--HG--
extra : amend_source : c815ae1200e6a615f932ddf36fba6f8a7a039500
This patch produces the following serialization:
```
input | computed value
------------------------------
1. "auto" "auto"
2. "auto auto" "auto"
3. "15px auto" "15px"
4. "15px" "15px"
```
i.e. If the second value is 'auto', then it's omitted from our serialization,
because it's implied.
Besides, we update the wpt to address this spec issue:
https://github.com/w3c/csswg-drafts/issues/2574
Differential Revision: https://phabricator.services.mozilla.com/D35510
--HG--
extra : moz-landing-system : lando
This test is supposed to check CSS property support, but using
hasOwnProperty() is causing a lot of false positive because
hasOwnProperty() doesn't go up the proto chain even if the property
is actually supported.
Differential Revision: https://phabricator.services.mozilla.com/D35512
--HG--
extra : moz-landing-system : lando
Currently Firefox creates a 2D DOMMatrix when certain values of 16 elements are zero, so this change fixes it to align with the spec.
Differential Revision: https://phabricator.services.mozilla.com/D35326
--HG--
extra : moz-landing-system : lando
This matches the recommendation at:
https://web-platform-tests.org/writing-tests/ahem.html
...and it makes this test start passing. Without this change, the default
`line-height:normal` behavior effectively behaves like `line-height:1.2` in
Firefox, which creates some space between the content and the container's top
border, which makes the test fail.
Differential Revision: https://phabricator.services.mozilla.com/D35380
--HG--
extra : moz-landing-system : lando
There is a weird rendering (or CSS) issue that the background box is little bit larger than the one in the test file, which causes test failure on Android.
Differential Revision: https://phabricator.services.mozilla.com/D35276
--HG--
extra : moz-landing-system : lando
The default margin-top of h1 is 0.67em in Firefox (specified in
layout/style/res/html.css) as well as in Google Chrome.
The test reference tries to override it to avoid margin-collapse, but
using 0.66em can cause rounding issue on MacOS that make the test
failed.
Differential Revision: https://phabricator.services.mozilla.com/D32063
--HG--
extra : moz-landing-system : lando
We used to apply the column container's block size constraint on top of
the available block size in nsColumnSetFrame::ChooseColumnStrategy().
After column-span is enabled, ColumnSet is no longer the outermost
column container frame. We need to apply ColumnSetWrapper's block size
constraint to the available size when creating the ReflowInput for
ColumnSet so that ColumnSet can use it to compute the max column block
size in ChooseColumnStrategy().
This is calculated in nsBlockFrame::ReflowBlockFrame() instead of
nsColumnSetFrame::ChooseColumnStrategy() because we need
BlockReflowInput::mBCoord to determine the remaining block size.
multicol-breaking-004.html is copied and modified from
multicol-breaking-001.html with border-bottom added to test
"box-decoration-break: clone".
Differential Revision: https://phabricator.services.mozilla.com/D31676
--HG--
extra : moz-landing-system : lando
According to the spec 7.2.10.17 [1], if we have tried both direction and there is no place to put the cue inside the rendering area without overlapping with other cues or the boundary of rendering area, then we have to discard all CSS boxes, which means that we should not display this cue.
Therefore, I added the cue's text content in `very_long_cue.vtt` in order to let it exceed the boundary of the rendering area during display.
[1] https://www.w3.org/TR/webvtt1/#processing-cue-settings
Differential Revision: https://phabricator.services.mozilla.com/D33358
--HG--
extra : moz-landing-system : lando
Should not serialize default shape-outside circle() function radius.
The ToCss impl of Circle and Ellipse turn out to be identical in specified and computed value, thus move them to generics.
Differential Revision: https://phabricator.services.mozilla.com/D35183
--HG--
extra : moz-landing-system : lando
Should not serialize default shape-outside circle() function radius.
The ToCss impl of Circle and Ellipse turn out to be identical in specified and computed value, thus move them to generics.
Differential Revision: https://phabricator.services.mozilla.com/D35183
--HG--
extra : moz-landing-system : lando
These wpt are actually able to pass without having any modification, we should enable them.
Differential Revision: https://phabricator.services.mozilla.com/D34103
--HG--
extra : moz-landing-system : lando
Add a new wpt 'start_alignment.html' to ensure that two cues would have different text alignment.
In addition, add `line:0` in vtt file to put cue on the top in order to reduce the complexity of using CSS to markup the test, because if we don't specifiy the postion for cue, those two cues won't be put the bottom of the video, instead they would be move upward one line above the bottom according to the spec.
The reason is that the base moving unit for adjusting cue box's position is the Bsize of the first line box, it would require extra moving if one cue contains two different cues which line boxes are not the same height.
Differential Revision: https://phabricator.services.mozilla.com/D34641
--HG--
extra : moz-landing-system : lando
Disable on Windows is because sometime iframe can't load successfully, which makes our test file showing wrong image.
Differential Revision: https://phabricator.services.mozilla.com/D34778
--HG--
extra : moz-landing-system : lando
Enable the web platform tests for clearkey scheme checking. Since these tests
simply check if the functionality is implemented, and do not check if the
browsers actually support different encryption schemes, it's okay to do this
even though we don't have cbcs support in clearkey yet. I.e. it's enough that a
page can ask "do you support cbcs in clearkey?" to Firefox to pass the test, the
answer from Firefox doesn't have to be "yes."
Add the pref setting to the DRM scheme checking test, though leave the
expectations as they are on this test, as in automation the test will still not
pass due to Widevine downloads being blocked. My hope is that we can find a
solution to this Widevine download issue in automation, at which point we'd
expect that tests to start passing due to the pref added in this patch -- at
which point we could toggle the expectations.
Differential Revision: https://phabricator.services.mozilla.com/D34303
--HG--
extra : moz-landing-system : lando
I want to enable in Nightly to evaluate (in the medium term) shipping it without
the part forwarding, once the cascade order and importance issues are fixed, and
that we pass all the tests that don't involve forwarding.
That is, I want to monitor whether having ::part() causes compat issues or not.
Depends on D32648
Differential Revision: https://phabricator.services.mozilla.com/D32649
--HG--
extra : moz-landing-system : lando
The idea is to check IsBidiSplittable() in more places to prevent fixed
continuations created by column-span from becoming fluid ones.
Differential Revision: https://phabricator.services.mozilla.com/D34093
--HG--
extra : moz-landing-system : lando
This patch implements the majority of the planned picture caching
improvements. It supports most of the functionality required to
(as a follow up) support OS compositor integration. It also improves
on the robustness and functionality of the previous picture caching
implementation.
There are some expected temporary performance regressions in
some cases (such as content that is constantly invalidating) and
during initial page render when many render targets must be drawn
to. These performance regressions will be resolved in follow up
commits by supporting multi-resolution tiles.
The scene is split into a number of slices, determined by the scroll
root of each primitive, which can be found by the primitive's
spatial node indices. If a scene contains too many slices, then
picture caching is disabled on the page, to avoid excessive texture
memory usage, and rendering falls back to rasterizing each frame.
The specific changes in this patch are:
* Support tile caches for multiple scroll roots, allowing the
entire page (including fixed divs and the main UI bar) to be
cached in most cases, in addition to the main content.
* Remove requirement to read tiles back from the framebuffer.
Instead, they are drawn into the picture cache target tiles,
and blitted to the screen. This is slightly slower than the
existing picture caching when content is constantly changing,
however this cost will disappear / become irrelevant when
the OS compositor integration work is complete.
* Switch picture cache render targets to be nearest sampled (they
are always rendered 1:1) and support depth buffer targets.
* Make use of the external scroll offset support to allow removal
of the primitive correlation hacks in the previous picture
caching implementation. Also allows storing of primitive
dependencies in picture space rather than world space, which
reduces floating point inaccuracies.
* Determine if each tile and picture cache can be considered
opaque. This is used to determine whether subpixel AA text
rendering is available on a slice, and for rendering optimizations
related to disabling blending and/or tile clears.
* Use the clip chain instance results from the recent visibility pass
work to determine clip chain dependencies. This results in fewer
clip item dependencies in tiles, which is faster to check validity
and reduces redundant invalidations.
* Remove extra overhead during batching related to batch lists,
and region iteration, as they are no longer required.
* Support PrimitiveVisibilityMask during batching. This allows a
single traversal of a picture (surface) root during batching to
efficiently construct multiple alpha batcher objects (typically
one per invalida tile).
* Picture caching is now handled implicitly by WR, depending on
the content of the scene. There is no requirement for client
code to manually select which stacking context should be cached.
* Simplify how clip chain / transform dependencies are tracked by
picture cache tiles.
* Support pushing / popping enclosing clip chain roots without
the need for a stacking context / picture in some cases. This
simplifies the logic to split the scene into multiple slices.
The main remaining work in this area is (a) extend the code to
optionally provide each slice as an input to the OS compositor
rather than drawing the tiles in WR, and (b) support multi-resolution
tiles so that we reduce the draw call, batching and render target
overhead in cases where much of the page content is changing.
Differential Revision: https://phabricator.services.mozilla.com/D34319
--HG--
extra : moz-landing-system : lando
Currently, there are no tests of `execCommand()` without editable element.
Additionally, current Gecko propagate "cut" and "copy" commands into child
document (I think it's odd).
This test checks the behavior. The expected results are considered mainly
from Chrome, but also Chrome does not pass all tests because some their
behavior are odd. E.g., Chrome returns `true` for `execCommand("styleWithCSS")`
even though it does nothing. So, this patch makes its expected result `false`.
Differential Revision: https://phabricator.services.mozilla.com/D29627
--HG--
extra : moz-landing-system : lando
This makes it request a different ideal resolution and accepts anything in
between the original and the requested resolution.
Differential Revision: https://phabricator.services.mozilla.com/D32967
--HG--
extra : moz-landing-system : lando
They're not used internally either, so remove all ability to address them.
I haven't removed the implementation yet, as some of them are quite complex, and
I don't have a mac / windows build. We should do that when this hits release
though.
Differential Revision: https://phabricator.services.mozilla.com/D32488
--HG--
extra : moz-landing-system : lando
The test should work once after we fixed an issue on the interaction between
layer-pixel alignment and scrolling APIs in bug 1556685.
Differential Revision: https://phabricator.services.mozilla.com/D33610
--HG--
extra : moz-landing-system : lando
One test case for the from-font feature is expected to fail (noted in it's ini file), when this is implemented later it should pass
Differential Revision: https://phabricator.services.mozilla.com/D33370
--HG--
extra : moz-landing-system : lando
(The pref is about to be removed, but even before its removal, it defaults to
'true' so these tests don't need to bother setting/checking it.)
Differential Revision: https://phabricator.services.mozilla.com/D33805
--HG--
extra : moz-landing-system : lando
Also, in many place, we use document uri as referrer. It is not right
for the case srdoc iframe. We should use the last non-srdoc parent
document's uri
Differential Revision: https://phabricator.services.mozilla.com/D30191
--HG--
rename : testing/web-platform/tests/referrer-policy/generic/iframe-inheritance.html => testing/web-platform/tests/referrer-policy/generic/inheritance/iframe-inheritance-data.html
rename : testing/web-platform/tests/referrer-policy/generic/iframe-inheritance.html => testing/web-platform/tests/referrer-policy/generic/inheritance/iframe-inheritance-srcdoc.html
extra : moz-landing-system : lando
This test only contains simple API behavior test, which is not possible to be affected by web-render.
Differential Revision: https://phabricator.services.mozilla.com/D32870
--HG--
extra : moz-landing-system : lando
The stack isn't always deep enough to get to LoadInfo, so add another
fairly distinct frame that is closer to the top of the stack. I also
noticed an instance of this failure in the service-worker directory,
so I added the whitelisting there, too.
Differential Revision: https://phabricator.services.mozilla.com/D33091
--HG--
extra : moz-landing-system : lando
There is no need to add `max-asserts` for those two wpts, they are running correctly without hitting any assertion.
Differential Revision: https://phabricator.services.mozilla.com/D32869
--HG--
extra : moz-landing-system : lando
Recent CSP changes added some new stacks to big page leaks, so add
LoadInfo to some WPT white lists.
Differential Revision: https://phabricator.services.mozilla.com/D32501
--HG--
extra : moz-landing-system : lando
The only different part is to resolve intrinsic image size. This patch
implements explicit requirements of the spec, but an edge case is tricky.
It's not clear per spec what the intrinsic image size is for an SVG
without explicit width/height, something like:
<svg>
<image href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg'><rect width='40' height='90' fill='red' /></svg>"/>
</svg>
Chrome treats the intrinsic size of the href svg as the default size of
a replaced element (300x150), our image/VectorImage.cpp doesn't resolve
size in this case.
We can handle this particular case in some seperate bug if necessary, I think.
Differential Revision: https://phabricator.services.mozilla.com/D32415
--HG--
extra : moz-landing-system : lando
We previously (in bug 1491235) adjusted some utility code to make
layout-contained frames behave as if they have no baseline.
But that's not sufficient. To make frames fully report lack-of-a-baseline,
we now do the following for layout-contained frames, as of this patch:
(a) We now leave the ReflowOutput outparam's BlockStartAscent member at its
default value (which is what we do for frames without a baseline like
e.g. nsCheckboxRadioFrame and nsHTMLCanvasFrame). And if the parent cares
about the baseline, it'll then ask directly, using a baseline getter.
(b) We now return 'false' in more implementations of bool-returning
baseline-getter-methods (where 'false' indicates 'no baseline').
(c) We now return the margin-box-bottom edge, in the nscoord-returning
'GetLogicalBaseline()' getter method. (We typically do this by deferring
to the inherited method, which ultimately comes from nsFrame's
implementation). It's appropriate to use the margin-box-bottom edge when
there's no baseline, per the definition of 'vertical-align: baseline',
here: https://drafts.csswg.org/css2/visudet.html#propdef-vertical-align
Depends on D32182
Differential Revision: https://phabricator.services.mozilla.com/D32183
--HG--
extra : moz-landing-system : lando
In particular:
- In contain-layout-suppress-baseline-002.html, the test currently indirectly
relies on the 50px-tall-canvas being the tallest thing in each flex
container. This isn't robustly true (and in fact on windows, the textarea is
taller at 50.8px tall). So I'm adjusting this test so that it no longer has a
hardcoded flex container size and no longer depends on this.
- In contain-layout-baseline-005.html and its reference case, we need to
explicitly specify 'vertical-align:baseline' to test baseline-alignment,
because some of its tested form controls have other UA-stylesheet-provided
default values of 'vertical-align'.
(e.g. <select multiple> defaults to 'vertical-align:text-bottom")
- Also: in that same test, we need to reduce the width of the an <input>
textfield -- otherwise, it and the other elements on its line may not fit and
may linewrap, which prevents us from effectively testing baseline-alignment
on the linewrapped element.
- In contain-layout-button-001.html, the expectation was not correct. Before
this patch, the test expects that a layout-contained button will have the
same baseline as an empty button, and that's an invalid expectation. An empty
button uses a point inside of its content-box as its baseline, whereas a
layout-contained element *has no baseline*, which means that it does
'vertical-align:baseline' alignment by aligning its own margin-bottom edge
with the parent's baseline, per
https://drafts.csswg.org/css2/visudet.html#propdef-vertical-align
So, I'm amending the test to have this expectation and updating its meta tags
to reference the updated expectation and with a reference to that spec text.
Firefox fails the amended contain-layout-button-001.html test, so this patch
adds a .ini file to reflect that failure. The next patch in this series will
fix our implementation to make us pass the test, and will remove the .ini file.
Chrome also fails the amended contain-layout-button-001.html tests, and I filed
https://bugs.chromium.org/p/chromium/issues/detail?id=965740 on them with an
explanation.
Differential Revision: https://phabricator.services.mozilla.com/D32182
--HG--
extra : moz-landing-system : lando
This includes style system and layout update. I add 3 extra reftests
because the original tests use ray() function as the offset-path, but we
don't support it. It'd be better to add tests using a different type of
offset-path.
The spec issue about the serialization:
https://github.com/w3c/fxtf-drafts/issues/340
Differential Revision: https://phabricator.services.mozilla.com/D32212
--HG--
extra : moz-landing-system : lando
We previously (in bug 1491235) adjusted some utility code to make
layout-contained frames behave as if they have no baseline.
But that's not sufficient. To make frames fully report lack-of-a-baseline,
we now do the following for layout-contained frames, as of this patch:
(a) We now leave the ReflowOutput outparam's BlockStartAscent member at its
default value (which is what we do for frames without a baseline like
e.g. nsCheckboxRadioFrame and nsHTMLCanvasFrame). And if the parent cares
about the baseline, it'll then ask directly, using a baseline getter.
(b) We now return 'false' in more implementations of bool-returning
baseline-getter-methods (where 'false' indicates 'no baseline').
(c) We now return the margin-box-bottom edge, in the nscoord-returning
'GetLogicalBaseline()' getter method. (We typically do this by deferring
to the inherited method, which ultimately comes from nsFrame's
implementation). It's appropriate to use the margin-box-bottom edge when
there's no baseline, per the definition of 'vertical-align: baseline',
here: https://drafts.csswg.org/css2/visudet.html#propdef-vertical-align
Depends on D32182
Differential Revision: https://phabricator.services.mozilla.com/D32183
--HG--
extra : moz-landing-system : lando
In particular:
- In contain-layout-baseline-005.html and its reference case, we need to
explicitly specify 'vertical-align:baseline' to test baseline-alignment,
because some of its tested form controls have other UA-stylesheet-provided
default values of 'vertical-align'.
(e.g. <select multiple> defaults to 'vertical-align:text-bottom")
- Also: in that same test, we need to reduce the width of the an <input>
textfield -- otherwise, it and the other elements on its line may not fit and
may linewrap, which prevents us from effectively testing baseline-alignment
on the linewrapped element.
- In contain-layout-button-001.html, the expectation was not correct. Before
this patch, the test expects that a layout-contained button will have the
same baseline as an empty button, and that's an invalid expectation. An empty
button uses a point inside of its content-box as its baseline, whereas a
layout-contained element *has no baseline*, which means that it does
'vertical-align:baseline' alignment by aligning its own margin-bottom edge
with the parent's baseline, per
https://drafts.csswg.org/css2/visudet.html#propdef-vertical-align
So, I'm amending the test to have this expectation and updating its meta tags
to reference the updated expectation and with a reference to that spec text.
Firefox fails the amended contain-layout-button-001.html test, so this patch
adds a .ini file to reflect that failure. The next patch in this series will
fix our implementation to make us pass the test, and will remove the .ini file.
Chrome also fails the amended contain-layout-button-001.html tests, and I filed
https://bugs.chromium.org/p/chromium/issues/detail?id=965740 on them with an
explanation.
Differential Revision: https://phabricator.services.mozilla.com/D32182
--HG--
extra : moz-landing-system : lando
ScrollToShowRect calls nsIScrollableFrame::ScrollTo with an nsRange which
will be used to constrain the final scroll position so that if snapping needs
to happen we need to ignore the given range not to constrain the final
destination position in the range.
Differential Revision: https://phabricator.services.mozilla.com/D31948
--HG--
extra : moz-landing-system : lando
ScrollToShowRect calls nsIScrollableFrame::ScrollTo with an nsRange which
will be used to constrain the final scroll position so that if snapping needs
to happen we need to ignore the given range not to constrain the final
destination position in the range.
Differential Revision: https://phabricator.services.mozilla.com/D31948
--HG--
extra : moz-landing-system : lando
The test still fails, but now the failure is an issue with the feature rather
than the harness.
Differential Revision: https://phabricator.services.mozilla.com/D31352
--HG--
extra : moz-landing-system : lando
Because the IPDL channel between HttpChannelChild/Parent is sensitive to chaos
mode delays, sometimes the channel will be cancelled before completing, other
times after.
Because of this, the test will sometimes fail in verify mode.
Differential Revision: https://phabricator.services.mozilla.com/D31984
--HG--
extra : moz-landing-system : lando
This patch makes SVG retrieve metrics from CSS style.
It doesn't handle <svg> element because geometry properties for
outer <svg> element has been partially implemented long ago, it
needs special change.
It doesn't deal with the impact on SMIL.
Differential Revision: https://phabricator.services.mozilla.com/D29992
--HG--
extra : moz-landing-system : lando
This patch adds SVG geometry properties to CSS, it doesn't deal with
how SVG handles them.
Differential Revision: https://phabricator.services.mozilla.com/D29937
--HG--
extra : moz-landing-system : lando
Note that the "loose | normal | strict" values are not yet parsed/implemented.
Differential Revision: https://phabricator.services.mozilla.com/D29817
--HG--
extra : moz-landing-system : lando
