We send offset-position to the compositor, just like other similar
properties, e.g. offset-rotate, offset-anchor. This includes extracting
this animation value, doing serialization and sending it via IPC.
So now we can run the animation of ray() on the compositor properly.
Differential Revision: https://phabricator.services.mozilla.com/D179862
It's unnecessary to implement ToAnimatedZero for this property and so we
return Err(()), just like other properties which also use basic shapes,
e.g. clip-path, shape-outside.
Differential Revision: https://phabricator.services.mozilla.com/D179859
When the content having `content-visibility: auto` and the specific value for `contain-intrinsic-size` is slightly out of the viewport,
its computed value keeps changing.
This patch makes `content-visibilty: auto` forces `contain-intrinsic-size` to gain an auto value to solve this issue.
Differential Revision: https://phabricator.services.mozilla.com/D174583
Now it supports "normal" keyword. Also, offset-position doesn't create
stacking context and it doesn't have offset transform, so we can
simplify CompareMotionValues() a little bit.
Note: We don't have to add test in [1] because Blink added one to WPT
upstream repo already.
[1] css/motion/parsing/offset-position-parsing-valid.html
Note: the usage of offset-position is in other bugs.
Differential Revision: https://phabricator.services.mozilla.com/D179623
Make the computed value of border-like properties app units (which is
effectively what happens in Gecko already), and clamp at computed value
time.
Differential Revision: https://phabricator.services.mozilla.com/D179481
For any element that anchors a `:has()` selector (i.e. Matches a selector that
contains a `:has()` on its rightmost side), we prevent style sharing altogether,
as evaluation of the `:has()` selector is required in the first place to
determine style sharing.
On the other hand, any element matching a rule containing `:has()` without
anchoring it can do style sharing for siblings, but not cousins.
Differential Revision: https://phabricator.services.mozilla.com/D176836
This is necessary to properly report changes in our document.
The remaining failures are about change event scheduling, which is a
pre-existing issue. Will fix, but in a separate bug.
Differential Revision: https://phabricator.services.mozilla.com/D178917
If this happens again, it might be worth not matching rather than
potentially crashing. Though I guess crashing is a very good way getting
it reported soon...
Differential Revision: https://phabricator.services.mozilla.com/D178921
I was looking into simplifying our scrollbar styles:
* StyleAppearance::Resizer is not used in content, and some of the
values were only for <xul:window> which are not supported anymore.
* Statusbarpanel and Resizerpanel aren't used. Statusbar is only used
once on macOS so we only need to keep it there.
Differential Revision: https://phabricator.services.mozilla.com/D178374
This adds two prefs to configure the parallel traversal work item size
and kick-off threshold, but otherwise shouldn't change behavior.
I switched from iterator generics to just a slice while at it, mostly
for simplicity, but there is a trade-off:
* When switching from sequential to parallel traversal, we potentially
pay the price of memmoving the VecDeque around once to make them a
contiguous slice.
* However we win in the common case of the smaller-than-work-unit size
in which case we no longer need to copy stuff to a WorkItem. So I
think overall this should be an improvement.
Differential Revision: https://phabricator.services.mozilla.com/D178656
Implemented behind the new properties-and-values pref.
Support for the CSSPropertyRule WebIDL interface is also added in this
patch, because until it's added, any attempt to access the rule using
the CSSOM would crash the browser.
Depends on D178268
Differential Revision: https://phabricator.services.mozilla.com/D178270
Per CSS shape spec, the empty path string is invalid. However, for SVG
d property, the EBNF allows the path data string in the d property to be
empty. We just disable the rendering of the path.
Note: only offset-path and clip-path are affected.
Differential Revision: https://phabricator.services.mozilla.com/D178123
Plumb everything up. This factors out declaration and rule parsing so
we share the code with the regular declaration parser.
This could be made a bit nicer in the future. We need to decide what to
do for @page and @keyframe (it seems conditional rules inside ought to
work, but that's not so easy because per spec we create a nested style
rule).
But this is a first pass that passes a good chunk of the tests. There
are other fixups to cssom, and I think some of the tests we fail are
actually wrong...
Differential Revision: https://phabricator.services.mozilla.com/D178266
This is a relatively small code size regression (130k on windows and
macOS, 180k on Linux), for a few high confidence improvements in
speedometer 3. See link in the bug.
If this sticks, we can actually clean up a bunch of code, and eventually
unify RefPtr and nsCOMPtr. But I want this to be on the tree for a while
before doing more aggressive refactorings / actually removing the code.
Differential Revision: https://phabricator.services.mozilla.com/D178267
This changes the cssparser setup to:
* Avoid having to do copies of the ParsingContext all over the place,
which is useful because I plan to stash more nesting state in there.
* Use the new RuleBodyParser which allows parsing qualified rules,
declarations, and so on. Though we still don't use this anywhere.
The next step is to join NestedRuleParser and PropertyDeclarationParser,
so that we can parse declarations in a lot of the nested rules as well.
Differential Revision: https://phabricator.services.mozilla.com/D178053
Unlike the `ParseRelative` flag, which turns on relative selector parsing for
that parsing level only, the newly added `DISALLOW_RELATIVE_SELECTOR` flag
propagates through nested parsing calls.
Differential Revision: https://phabricator.services.mozilla.com/D176807
This simplifies a tiny bit our bindings in some places, and complicates
it in others, but over all I think it's better.
It requires a bit more manual code in the rust side to drop and cast the
relevant pointers (which was done implicitly before), but it's a lot
less magic than it used to be, and that's all autogenerated so consumers
don't need to care about it.
The set up is still not ideal. I don't like that we rely on destructors
running in both sides of the FFI boundary, but that's for another day.
This is the last usage of RawOffsetArc, so remove that. We now support
proper Arc<> in structs (GridTemplateAreas uses it), so I don't think
we'll need it any time soon.
Differential Revision: https://phabricator.services.mozilla.com/D177905
