Avoid processing anon content in nsCanvasFrame, then getting more anon content
via AccessibleCaretEventHub::Init. Instead call Init before creating the custom
content container. We could also throw a script runner at it I guess, but this
prevents the reentrancy issue.
Avoid cloning nodes during layout, just use the same node (already cloned in
InsertAnonymousContent) instead.
The RemoveChild in GetAnonymousContent to handle the reframes instead of cloning
around is a bit hacky, but I don't think it's really worth extending
PostDestroyData for this special case.
Differential Revision: https://phabricator.services.mozilla.com/D1889
Most of the removed tests are specific to listbox code, some are related to fixes already covered elsewhere, and some have no associated fix and were originally checked in just for good measure.
MozReview-Commit-ID: 3AQXoKy6HhU
--HG--
extra : rebase_source : 88781275bfdb436c0bb4249972435ad74e95002e
This preference controls whether authors are allowed to specify animations
without a 0% or 100% keyframe.
We intend to ship this soon but this preference acts as a safeguard in case we
discover we need to disable it.
This feature is very convenient and commonly used so this patch ensures it is
always enabled for system content.
MozReview-Commit-ID: BHTsuS2xO61
--HG--
rename : dom/animation/test/mozilla/file_disable_animations_api_core.html => dom/animation/test/mozilla/file_disable_animations_api_implicit_keyframes.html
rename : dom/animation/test/mozilla/test_disable_animations_api_core.html => dom/animation/test/mozilla/test_disable_animations_api_implicit_keyframes.html
extra : rebase_source : 04fd93dd26a4765c14b0b22febdb0311b650ea59
This gets set to a non-zero value when we have an inactive ContainerLayer ancestor (filter in this case).
The current code assumes we'd never call BuildLayer on an image when that happen, but we force the pseudo-active
state here because background-position is animated (all properties have a transition).
MozReview-Commit-ID: 6pL8EJTNgWy
--HG--
extra : rebase_source : 6370fc79d5f47f0b5c4bbe86c0b605b90256b653
Since the test relies on missing keyframes handling.
MozReview-Commit-ID: IfbMvRhIeOh
--HG--
extra : rebase_source : 447bec6c7bc8d8a79f00bb738182e0647ee68ec5
Continuations do not have placeholders. There's a bunch of code that already
deals with that in other places in the tree.
MozReview-Commit-ID: Htizql7692e
In this case we have a shadow hoot with display: contents, with no children.
Those children wouldn't be flattened tree children of the shadow host.
Instead of using the last light dom child and seek to it, use
FlattenedChildIterator's reverse iteration.
MozReview-Commit-ID: 18XL5Ong7ww
--HG--
extra : rebase_source : 2d34bd5b1fdd509a069ffa5052a7b7b3302be24c
We probably need more fixes for counters and Shadow DOM. The spec only mentions
"document order", and this is the most reasonable thing to do accounting for
shadow DOM in that regard...
This ensures a reasonable behavior for all callers which pretty much expect
otherwise for all children to be connected.
MozReview-Commit-ID: YEQIKdjRTK
--HG--
extra : rebase_source : 9b31f5d00d270cf21476776144d62350b5453f99
This also adopts the resolution of [1] while at it, and switches XUL to not
support display: contents until a use case appears.
This makes our behavior consistent both with the spec and also in terms of
handling dynamic changes to stuff that would otherwise get suppressed.
Also makes us consistent with both Blink and WebKit in terms of computed style.
We were the only ones respecting "behaves as display: none" without actually
computing to display: none. Will file a spec issue to get that changed.
It also makes us match Blink and WebKit in terms of respecting display: contents
before other suppressions, see the reftest which I didn't write as a WPT
(because there's no spec supporting neither that or the opposite of what we do),
where a <g> element respects display: contents even though if it had any other
kind of display value we'd suppress the frame for it and all the descendants
since it's an SVG element in a non-SVG subtree.
Also, this removes the page-break bit from the display: contents loop, which I
think is harmless.
As long as the tests under style are based in namespace id / node name /
traversal parent, this should not make style sharing go wrong in any way, since
that's the first style sharing check we do at [2].
The general idea under this change is making all nodes with computed style of
display: contents actually honor it. Otherwise there's no way of making the
setup sound except re-introducing something similar to all the state tracking
removed in bug 1303605.
[1]: https://github.com/w3c/csswg-drafts/issues/2167
[2]: https://searchfox.org/mozilla-central/rev/fca4426325624fecbd493c31389721513fc49fef/servo/components/style/sharing/mod.rs#700
MozReview-Commit-ID: JoCKnGYEleD
The old style system can't find the appropriate style to inherit from when
::first-line and display: contents are involved...
MozReview-Commit-ID: 98t1ABgLulQ
It doesn't make sense, since they have no frame themselves, and it breaks
invariants other code relies on. Use the parent frame instead.
The stack overflow happens because we give the first-letter frame to the
display: contents element, then we reframe it.
Removing a display: contents node calls ContentRemoved on all the children. One
of these children is this text-node inside the first-letter frame. Since it was
split by bidi resolution we go ahead and reframe the parent in:
https://searchfox.org/mozilla-central/rev/d2b4b40901c15614fad2fa34718eea428774306e/layout/base/nsCSSFrameConstructor.cpp#9688
But the parent is the display: contents node, which results in infinite
recursion.
The usage of GetParent() is wrong anyway too, since it doesn't handle XBL or
Shadow DOM in any way.
MozReview-Commit-ID: JFD16at316V
--HG--
extra : rebase_source : e485b45bc146a70c26f8534f760899218da07500