While we're here, don't re-recompute the default computed values, just grab them
from the device.
MozReview-Commit-ID: GqqnPLIwN2F
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
We create the SequentialTask only if:
* We have no old computed values and we have animation name style in the new
computed values.
* Any animation properties is changed.
* display property is changed from 'none' and we have animation name style.
* display property is changed to 'none'.
In a subsequent patch we skip the SequentialTask if we have no running
animations and the display propery is changed to 'none'.
MozReview-Commit-ID: JRSZznufOS2
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 idea is to be able to call the right function during style resolution time
without doing a linear walk via nsCSSAnonBoxes::IsNonInheritingAnonBox.
MozReview-Commit-ID: JKt33GggTjz
This introduces a basic framework for servo's style system to be able
to query the style of presentation attributes which it can then insert
into the cascade. It uses that framework to implement the size and
color attributes on <font>.
There are a number of improvements that can be done on top of this:
- Implement all other properties
- Abstractify the ruledata parameter of the mappers using templates or virtual dispatch so that it can be a Servo decl block instead
- Implement aforementiond abstraction over Servo decl blocks (this obsoletes the code in the first item above, so it might just be better to skip that and directly do this)
- Replace uses of nsHTMLStyleSheet with an abstract base class containing common elements between Servo and Gecko
I'd prefer for these to be done in separate steps.
MozReview-Commit-ID: GO60qfeZOfl
The setup is quite different to Servo-land, so add a comment about the different
setup.
Also, check viewport rules when flushing stylesheets. I believe that the
previous behavior is plain wrong, though I haven't taken the time to come up
with a test case.
In any case, it doesn't hurt any of both back-ends.
MozReview-Commit-ID: 46gtTkesOsr
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
We're incorrectly asserting that a sheet is applicable when we remove it from
the style set, but we'll actually cause the sheet to be not applicable just
before we remove it from the style set. (Note how nsStyleSet doesn't assert
this in RemoveStyleSheet.) Also, we were missing a corresponding assertion
in AddDocStylesSheet.
MozReview-Commit-ID: E5qwxwrA74F
I noticed that our current behavior in ContentRangeInserted is incorrect. Unlike
ContentInserted (where this code lived originally), ContentRangeInserted takes a
start and end element. I'm not sure if we ever take that path for new content that
needs style, but it seemed sketchy. And generally, it seems nice to just always
style new content the same way (though we still need to style NAC by the subtree
root, since it hasn't been attached to the parent yet).
For situations where there is indeed only one unstyled child, the traversal
overhead should be neglible, since we special-case the single-element in
parallel.rs to avoid calling into rayon.
Being more explicit about what we want here also makes us more robust against
the other handful of callpaths that can take us into
nsCSSFrameConstructor::{ContentRangeInserted,ContentAppended}. Currently we
can call StyleNewSubtree on an already-styled element via RecreateFramesForContent,
which triggers an assertion in the servo traversal.
MozReview-Commit-ID: DqCGh90deHH
