The whitespace optimization code only knows about the light tree.
It's not a great idea to try to put flattened tree children of a slot through
there, since the children may not be assigned to the same slot, or to any slot
(in which case we crash).
We should probably rename XBLInvolved to ShadowDOMOrXBLInvolved too, I guess.
Note that the ShadowRoot case already sets the bit on Init().
MozReview-Commit-ID: 91lmE7OxlnA
--HG--
extra : rebase_source : ee87ae28d6065c7fd072afad61c16a59b6dce039
Just something I found while trying to construct a test-case for this.
MozReview-Commit-ID: A01qzQ14QG9
--HG--
extra : rebase_source : 5329a8791774b402b633a992fa9bca2cc5b320fb
Automatic update from web-platform-testsAllow Text node in elementsFromPoint if descendant of SVG text content
When hit-testing, SVG text content nodes will use their Text node
descendants as the inner-most/hit node, and hit-testing will not be
performed in any of the background phases. Thus we need to selectively
allow Text node which has an SVG text content element as their parent.
Bug: 842504
Change-Id: Ie282d5e9a66880f3f0d5e319b249f5f41db9e9db
Reviewed-on: https://chromium-review.googlesource.com/1059753
Commit-Queue: Fredrik Söderquist <fs@opera.com>
Reviewed-by: Philip Rogers <pdr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#561238}
--
wpt-commits: 65a5c24ba9769da8b103f72349ea111b124e54db
wpt-pr: 11130
Currently, NAC always inherits from the closest non-NAC ancestor element,
regardless of whether it is for an element-backed pseudo or not.
This patch changes the inheritance so that for element-backed pseudos, we
inherit from the closest native anonymous root's parent, and for other NAC we
inherit from the parent.
This prevents the following two issues and allows us to remove the
NODE_IS_NATIVE_ANONYMOUS flag:
* Avoiding inheriting from the non-NAC ancestor in XBL bindings bound to NAC.
- This is no longer a problem since we apply the rule only if we're a
pseudo-element, and all pseudo-elements are in native anonymous subtrees.
- This also allows to remove the hack that propagates the
NODE_IS_NATIVE_ANONYMOUS flag from the ::cue pseudo-element from
BindToTree.
* Inheriting from the wrong thing if we're a nested NAC subtree.
- We no longer look past our NAC subtree, with the exception of
::-moz-number-text's pseudo-elements, for which we do want to propagate
::placeholder to.
A few rules from forms.css have been modified because they're useless or needed
to propagate stuff to the anonymous form control in input[type="number"] which
previously inherited from the input itself.
MozReview-Commit-ID: IDKYt3EJtSH
Our behavior is correct, this uses the same setup that nsDocument and the
stylesets use, which I may look into fixing up / making more explicit in
bug 1465031.
MozReview-Commit-ID: 75AToXCw1pV
--HG--
extra : rebase_source : b7c11ca66b416c32b8fc0c5eedbc9383c63bad70
Automatic update from web-platform-testsfont-variant descriptor was moved to Fonts 4 (#11035)
* font-variant descriptor was moved to Fonts 4 https://github.com/w3c/csswg-drafts/issues/2531
* font-variant descriptor was moved to Fonts 4
--
wpt-commits: 232137f0fdacdeed99a7df5dd229d23020b0bccc
wpt-pr: 11035
Automatic update from web-platform-testsFix crash when setting aliases on computed style.
The incoming CSSPropertyID may be an unresolved property, therefore
CSSUnresolvedProperty::Get must be used rather than CSSProperty::Get.
This bug exists in Chrome stable as well, but it was pretty hard to
discover (by e.g. ClusterFuzz) because aliases were not enumerated until
recently.
R=futhark@chromium.org
Bug: 844816
Change-Id: I97c81764d2027f86004d3b02316cac44412ef0ea
Reviewed-on: https://chromium-review.googlesource.com/1065993
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Commit-Queue: Anders Ruud <andruud@chromium.org>
Cr-Commit-Position: refs/heads/master@{#560540}
--
wpt-commits: 94933315da3053196b82bb5d9e7a6a74cb550ce5
wpt-pr: 11100
Automatic update from web-platform-testsMerge pull request #11086 from w3c/rm-font-feature-settings-rendering-2
Delete font-feature-settings-rendering-2.html with font
--
wpt-commits: bba08e097cb74df656ff55f059757464eb700c91
wpt-pr: 11086
Some notes: this does not fully bring us to compliance to the current spec.
Instead, these are the fixes that I needed to make in order to make
css/geometry/interfaces.html pass with the DOMPoint changes in the previous
patches. I don't fully understand why that patch caused the test to fail the
way it did, but it ended up being easier to fix our code than understand why
the harness was falling over.
The DOMQuad::QuadBounds class was the source of some confusion for me. Now
that DOMRectReadOnly is a concrete class with members, I wanted to avoid
wasting them. However, the spec is unclear as to whether a DOMQuad's bound's
should be live -- that is because DOMQuad exposes DOMPoint, we can set its
points after retrieving a QuadBounds object. Our current code is live, setting
the points changes the QuadBounds. Chromium's current behavior is to never
update the QuadBounds object. I've left our behavior untouched in this patch
(and waste 4 doubles per QuadBounds object), but I am intending to file a bug
to understand what the intent of the spec is. I wonder if the author intended
the points to be DOMPointReadOnly instead. If so, we could simplify the
DOMRectReadOnly code and get rid of the virtual getters, which would be nice.
I also wasn't thrilled to put the DOMMatrix setters on the DOMMatrixReadOnly
class, but for brevity and simplicity of implementation, I've made them
public. I briefly considered making the setters protected on the ReadOnly
version of the class, but I'm not convinced that having to explicitly make
them public on the derived class is worth the extra copies of the names.
MozReview-Commit-ID: CjdW4Nbnc6A
--HG--
extra : rebase_source : 97e9386cfb17319242913d28117c8b1b8b6fbbbe
Automatic update from web-platform-testsMerge pull request #11083 from w3c/emilio-patch-1
[cssom] Make a test assertion not show the number of CSS properties if it fails.
--
wpt-commits: f7b5bce8110e0599c0fb22e47b816106877e36b6
wpt-pr: 11083
Automatic update from web-platform-testsCSS: Update WPT :matches for intersection behavior
".a+:matches(.c>.e)" requires the intersection of ".a+*" and ".c>.e",
not ".a+.c>.e".
WebKit passes the test, Blink's current implementation does not.
BUG=842157
Change-Id: I51566255006199c511b1d235232c0d9bef40035a
Reviewed-on: https://chromium-review.googlesource.com/1059982
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Commit-Queue: Eric Willigers <ericwilligers@chromium.org>
Cr-Commit-Position: refs/heads/master@{#560228}
--
wpt-commits: 19c90d8409b1c9b7d35e3fe012ff5c31fd750d58
wpt-pr: 11020
Automatic update from web-platform-tests[LayoutNG] Improve support for negative clearance.
When there are adjoining floats that need to be separated from a cleared
block, clearance is predetermined, and we have to force it on the block.
Any large top margin on the child will just be eaten by negative
clearance. There's nothing that can be done to prevent clearance in such
cases. So make sure that we don't try to determine whether to apply
clearance or not based on the clearance offset set in the constraint
space. When clearance has been predetermined (which may have triggered a
BFC offset resolution and what not), refusing to apply it to the child is
a bug.
This aligns the implementation with the "alternative" way of calculating
clearance in the spec [1]. Everyone but Edge does this. I think what
Edge does here is problematic, because it requires us to use a
hypothetical position that was calculated before clearance got applied
(clearance causes margins that would otherwise collapse to be
separated). We'd end up using a hypothetical position not based on the
actual layout situation.[2]
[1] https://www.w3.org/TR/CSS22/visuren.html#flow-control
[2] https://github.com/w3c/csswg-drafts/issues/2608
This fixes one existing test. Added a few new ones as well. Not all of
them failed prior to this CL, but they serve as regression tests for
things I found to lack coverage while working on this.
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_layout_tests_layout_ng
Change-Id: Ia45e9048c75c338477eee4923ff16eea3245bc6a
Reviewed-on: https://chromium-review.googlesource.com/1061470
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#560208}
--
wpt-commits: 499bf362082f5ca8679ad981536cbb38a98fccb3
wpt-pr: 11033
Automatic update from web-platform-testsAdd !important case to cssom-setProperty-shorthand.html (#11047)
Add !important case to cssom-setProperty-shorthand.html
to make sure the property is removed regardless [1].
[1] https://drafts.csswg.org/cssom/#dom-cssstyledeclaration-removeproperty
Change-Id: Ia68d224fb78a13f51bfeda02860932d56b1a0fba
--
wpt-commits: 2eca7cd9484fc2096859418c729889876129e636
wpt-pr: 11047
Automatic update from web-platform-tests[LayoutNG] Fix min/max sizes during layout and intrinsic passes.
Essentially this boils down to during min/max auto/percent/calc should be
treated the same, either being border+padding or infinity.
And during layout they should be taken into account.
I added some tests which now match FF/Edge (004,005) which LayoutNG matches, but
existing layout fails. The primary difference is change by passing kContent into
ResolveBlockLength during the ComputeBlockSizeForFragment function.
Bug: 635619
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_layout_tests_layout_ng
Change-Id: I4e0c171a0e29ea5d85a742d85df001647813c1f3
Reviewed-on: https://chromium-review.googlesource.com/1056291
Commit-Queue: Ian Kilpatrick <ikilpatrick@chromium.org>
Reviewed-by: Christian Biesinger <cbiesinger@chromium.org>
Reviewed-by: Morten Stenshorne <mstensho@chromium.org>
Cr-Commit-Position: refs/heads/master@{#559171}
--
wpt-commits: b06b08091c6a39d88957db2389727524258a3140
wpt-pr: 10994
Automatic update from web-platform-tests[css-contain] Layout containment abspos and fixed descendants
An element with "contain: layout" should be the containing block
of any absolutely or fixed positioned descendants.
The spec is very clear regarding this
(https://drafts.csswg.org/css-contain/#containment-layout):
"The element acts as a containing block for absolutely positioned
and fixed positioned descendants."
The patch just adds a new condition to
ComputedStyle::CanContainFixedPositionObjects().
We already had the condition for paint containment before,
so this takes advantage to add WPT tests to verify that case too.
This patch causes that contain-layout-005.html starts to fail,
but that's because of crbug.com/843329.
There are more failing tests related to that bug, so TestExpectations
is modified to reference it.
BUG=785212
TEST=external/wpt/css/css-contain/contain-layout-006.html
TEST=external/wpt/css/css-contain/contain-layout-007.html
Change-Id: I8bb1d637bd7742961a414a5007b8ee8a8d3e66ea
Reviewed-on: https://chromium-review.googlesource.com/1059557
Reviewed-by: Morten Stenshorne <mstensho@chromium.org>
Commit-Queue: Manuel Rego Casasnovas <rego@igalia.com>
Cr-Commit-Position: refs/heads/master@{#559045}
--
wpt-commits: 90f40cbe8452a84496c3e83bbba5b1de3f26455f
wpt-pr: 11026
