(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
This was added in bug 1384769 for passing into Servo_TakeChangeHint,
but bug 1388031 changed Servo_TakeChangeHint to no longer take it, and
there is nothing else in the function which uses the flags.
MozReview-Commit-ID: LvZkJZHENUB
This patch changes UpdateAnimationOnlyStyles to only flush animation styles if
there are throttled animation styles that could affect hit-testing and renames
the function to UpdateAnimationStylesForHitTesting at the same time.
For GeckoRestyleManager, the original UpdateAnimationOnlyStyles which flushes
animation styles if there are any pending animation styles, is renamed to
UpdateAnimationStyles for consistency.
MozReview-Commit-ID: 89UleXjI2OE
This doesn't actually implement style context reparenting in the style set yet; that part is next.
There is one behavior difference being introduced here compared to Gecko: we
don't reparent the first block piece of an {ib} (block-inside-inline) split
whose first inline piece is being reparented. This is actually a correctness
fix. In this testcase:
<style>
#target { color: green; }
#target::first-line { color: red; }
</style>
<div id="target">
<span>
<div>This should be green</div>
</span>
</div>
Gecko makes the text red, while every other browser makes it green.
We're preserving Gecko's behavior for out-of-flows in first-line so far, but
arguably it's wrong per spec and doesn't match other browsers either. We can
look into changing it later.
MozReview-Commit-ID: 5eC6G449Mlh
When we process throttled animations restyle for event handling, we skip normal
traversal at all, so after Servo_TraverseSubtree, normally there remains
unstyled elements which have to be processed in normal traversal later. These
elements should be skipped in ProcessPostTraversal too since it's not yet styled!
MozReview-Commit-ID: LgyWQpiFZ8e
Using SVG SMIL it is possible to animate the class attribute of an element using
markup such as the following:
<style>
.red {
fill: red;
}
</style>
<svg>
<circle cx="50" cy="50" r="30" fill="blue">
<set attributeName="class" to="red" begin="1s"/>
</circle>
</svg>
In Gecko, Element::GetClasses handles this case by looking for an animated class
string when the element in question is an SVG element.
This patch causes our Servo bindings to use GetClasses when querying attribute
values for selector matching.
Note that animating the class attribute is *not* expected to affect attribute
selectors such as `circle[class="red"]`. It does in Chrome, but that is due to
a Blink bug where animating attributes using SMIL affects the result of
getAttribute:
https://bugs.chromium.org/p/chromium/issues/detail?id=735820
This patch adjusts the behavior for both the GeckoElement case and the
ServoElementSnapshot case.
MozReview-Commit-ID: DAFWHSH1aYB
In particular, this fixes:
* Restyling of <area> elements that reuse the primary frame mapping for the
image map.
* Restyling of children of display: contents elements when the display:
contents element generates a hint.
* Restyling of out-of-flows (if my analysis in the bug is right).
* Restyling of the ::backdrop pseudo-element.
* Restyling of the Viewport frame.
I only managed to do a reftest for the second one, but the rest of them are
covered by the assertions added.
MozReview-Commit-ID: E7QtiQ1vPqu
This can happen with content attribute or state changes that end up not
generating any hint.
In particular, in the media_queries_dynamic.html case, the iframe resize was
toggling a few scrollbar attributes, which made us never pass the "didn't
restyle" test, even though the test really passed.
I'll probably need to add a workaround to assume we use viewport units, so
probably won't pass for long.
MozReview-Commit-ID: 2oEfic5yaOy
The difference is that PostRestyleEventForCSSRuleChanges sets
mRestyleForCSSRuleChanges true. In a subsequent patch,
we propagate a new TraversalRestyleBehavior flag to servo side
if mRestyleForCSSRuleChanges is true.
MozReview-Commit-ID: IKsBbm09uT9
We need to request an animation-only restyle to force flush all throttled
animations on main thread when we handle an event with coordinates
(e.g. mouse event).
MozReview-Commit-ID: KkjeQVsLgTl
I've chosen this approach mainly because there's no other good way to guarantee
the model is correct than holding the snapshots alive until a style refresh.
What I tried before this (storing them in a sort of "immutable element data") is
a pain, since we call into style from the frame constructor and other content
notifications, which makes keeping track of which snapshots should be cleared an
which shouldn't an insane task.
Ideally we'd have a single entry-point for style, but that's not the case right
now, and changing that requires pretty non-trivial changes to the frame
constructor.
MozReview-Commit-ID: FF1KWZv2iBM
We use RestyleManager::mAnimationGeneration as the animation index of a
new created transition, and Element.getAnimations() uses this index to
sort the order of transitions. We increase mAnimationGeneration one per
restyle cycle if there is any non-animation update.
MozReview-Commit-ID: KmirBzI7CXi
This patch exists to avoid a crash in layout/style/test/test_animations.html. We end up
generating some ::before content, which causes us to style the new subtree at [1]. In
StyleNewSubtree, we fail the !postTraversalRequired assertion because
PrepareAndTraverseSubtree decided to traverse the tree twice (once to style it, and again
to restyle it for animations), and return that a post-traversal is needed.
The reason this issue happens with my NAC patches and not without is that we were previously
filtering out generated ::before content from the servo traversal, so the servo traversal
wouldn't have reached it and (presumably) the animation restyle wouldn't have happened and
we wouldn't have returned true for needing a post-traversal.
[1] http://searchfox.org/mozilla-central/rev/c48398abd9f0f074c69f2223260939e30e8f99a8/layout/base/nsCSSFrameConstructor.cpp#1918
MozReview-Commit-ID: 8tgzLjV8B3A
The restyle request during restyling is a result of creating/updating/removing
CSS animations that will come from a SequentialTask which will be implemented
in a subsequent patch.
MozReview-Commit-ID: JoAqvcN3y51
The existing static_cast checks are totally wrong, by the way, since
nsIDocuments are never nsIContent. Looks like they were erroneously
added in bug 862763.
The current mechanism assumes that everything can be expressed in terms of restyle
hints, which has several limitations (in particular, we can't specify that a
subtree is dirty without also claiming that the root is dirty, since eRestyleSubtree
implies eRestyleSelf).
We may eventually decide that restyles hints give us everything we need, but while
we're experimenting I'd like the flexibility to do things both ways.
