Most of it is automated by:
%s/eStyleContentType_/StyleContentType::/g
%s/nsStyleContentType/StyleContentType/g
But I removed some parentheses by hand.
Bug: 1472443
Reviewed-by: xidorn
Differential Revision: https://phabricator.services.mozilla.com/D1900
This changes the order of properties returned from gCS. The old order
doesn't make much sense, and other browsers don't agree on an identical
order either, so it should be trivial to change it. Also the spec isn't
super clear / useful in this case.
Several -moz-prefixed properties are excluded from the list due to their
being internal. I suspect they are never accessible anyway, so probably
nothing gets changed by this.
Bug: 1471114
Reviewed-by: xidorn
MozReview-Commit-ID: 9LfangjpJ3P
The EffectSet count does not exactly represent the count what we really need
for AnimationValueMap, but in most cases it matches. For example;
1) The element has two different keyframes animations
@keyframes anim1 {
to { opacity: 0; }
}
@keyframes anim2 {
to { transform: rotate(360deg); }
}
In this case the number matches.
2) The element has two animations but both keyframes have the same CSS property
@keyframes anim1 {
to { opacity: 0; }
}
@keyframes anim2 {
to { opacity: 0.1; }
}
In this case the number doesn't match, moreover it results more memory than we
ever needed, but this case is presumably less common.
3) The element has an animation having keyframes for two different CSS
properties.
@keyframes anim {
from { opacity: 0; transform: rotate(360deg); }
}
In this kind of cases, the number doesn't match. But even so, this patch
reduces the opportunities that the AnimationValueMap tries to allocate a new
memory (i.e. less opportunities on expanding the map).
Note that when the hash map is expanded, we do allocate a new RawTable with the
new size then replace the old one with the new one [1], so I believe this
change will reduce the crash rate to some extent.
[1] https://hg.mozilla.org/mozilla-central/file/15c95df467be/servo/components/hashglobe/src/hash_map.rs#l734
Bug: 1418806
Reviewed-by: birtles
MozReview-Commit-ID: 6tcF9aqXh7a
After bug 1470163 we have some nasty selectors from mathml.css in every page.
We only want to match them against MathML elements.
This patch brings the global revalidation selectors from 14 to 2 in about:blank.
Also halves the ones from XUL documents.
Bug: 1374017
Reviewed-by: heycam
MozReview-Commit-ID: nOVyknNcVm
Do it so that we always try to evaluate the media expression and the modern
syntax last, so that the most specific error message comes up.
Bug: 1422225
Reviewed-by: xidorn
MozReview-Commit-ID: 2tqdAsWh6Kh
Which is more appropriate, given it represents a `<media-feature>` per spec, and
expression is a bit overloaded :)
Bug: 1422225
Reviewed-by: xidorn
MozReview-Commit-ID: Fed1nJhHxDu
The only bit from the spec which I haven't implemented to my knowledge is the
bit that allows you to swap the position of the media feature and the value,
because it unnecessarily complicates parsing (we parse the value in terms of the
feature), and I don't think it's useful given how easy it is to switch from,
e.g., `(500px > width)` to `(width <= 500px)`.
I filed https://github.com/w3c/csswg-drafts/issues/2791 about it.
Bug: 1422225
Reviewed-by: xidorn
MozReview-Commit-ID: 6xrdVl87S9X