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
