This is similar to this Chromium change:
https://codereview.chromium.org/1155353002
The editing spec doesn't mention editing non-HTML documents, and historically
this is only a feature that WebKit has supported. Supporting this feature
increases the attack surface of the browser without a clear benefit, so it
seems like a good idea to converge on this behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D32913
--HG--
rename : testing/web-platform/tests/html/editing/editing-0/making-entire-documents-editable-the-designmode-idl-attribute/user-interaction-editing-designMode.html => testing/web-platform/tests/html/editing/editing-0/making-entire-documents-editable-the-designmode-idl-attribute/user-interaction-editing-designMode-xml.xml
extra : moz-landing-system : lando
To avoid hitting the assertion for ResizeObserver, which calls GetBBox()
for all SVG elements.
Note:
If the target has SVG layout and its primary frame cannot be queries as
nsSVGDisplayableFrame, we return a default gfxRect(). And always
returning a default gfxRect() on <view> or <stop> element makes ResizeObserver
doesn't report it (because it is always not active). This behavior
is the same as what Google Chrome has. (i.e. No event is fired.)
Differential Revision: https://phabricator.services.mozilla.com/D32904
--HG--
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
I _think_ most of the sizes that get here are going to be equivalent to
mRect.Size(), but that seems really hard to prove.
Differential Revision: https://phabricator.services.mozilla.com/D32754
--HG--
extra : moz-landing-system : lando
This avoids a mismatch in the available arguments between upstream pip and
the version vendored into m-c at the cost of the code being more liable
to break when upstream changes.
Differential Revision: https://phabricator.services.mozilla.com/D32991
--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
This test is used to ensure that we queue 'honor user preferences for automatic text track selection' as a marco task, not a mirco task.
In this test, we would trigger a media event before queuing a text track selection task, and check the text track's mode to know whether the text track selection runs after the task for media event.
Differential Revision: https://phabricator.services.mozilla.com/D31921
--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
Always generating the slot assignment combinator means that we check the current
host correctly.
Differential Revision: https://phabricator.services.mozilla.com/D32405
--HG--
extra : moz-landing-system : lando
D29542 fixed the bogus checks that was making nested pseudo-elements match
author rules. This adds tests and ends up being just a cleanup, though as it
turns out we it also fixes an issue with ::slotted() matched from
Element.matches.
Differential Revision: https://phabricator.services.mozilla.com/D27529
--HG--
extra : moz-landing-system : lando
Ehsan Akhgari
Boris Chiou
Alastor Wu
Boris Zbarsky
Andrew McCreight
Emilio Cobos Álvarez
Byron Campen [:bwc]
James Graham
Mihai Alexandru Michis
Edgar Chen
Brindusan Cristian
Valentin Gosu
Bogdan Tara
Jonathan Kew
Kershaw Chang
Andrew Halberstadt
violet
Daniel Holbert