Always assume allowed-for-all-content. There are a couple callers which weren't
doing that:
* A unit test -> removed.
* ComputeAnimationDistance: Used for testing (in transitions_per_property), and
for the animation inspector. The animation inspector shouldn't show
non-enabled properties. The transitions_per_property test already relies on
getComputedStyle stuff which only uses eForAllContent.
* GetCSSImageURLs: I added this API for the context menu page and such. It
doesn't rely on non-enabled-everywhere properties, it was only using
eInChrome because it was a ChromeOnly API, but it doesn't really need this.
Differential Revision: https://phabricator.services.mozilla.com/D2514
We have a different order in nsCSSPropertyId for no good reason. The only
invariant there is that longhands come before shorthands, and shorthands before
aliases.
Luckily that's also an invariant that NonCustomPropertyId has, so we can reuse
them.
Differential Revision: https://phabricator.services.mozilla.com/D2463
MozReview-Commit-ID: 1hsQu6hmqiN
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
Summary:
This should make it easier to report errors, and also reduce codesize.
The reason this was so generic is that error reporting was unconditionally
enabled and was super-hot, but now that's no longer the case after bug 1452143,
so we can afford the virtual call in the "error reporting enabled" case.
This opens the possibility of simplifying a lot the error setup as well, though
this patch doesn't do it.
Test Plan: No behavior change, so no new tests.
Reviewers: xidorn
Bug #: 1469957
Differential Revision: https://phabricator.services.mozilla.com/D1734
MozReview-Commit-ID: F3wTdhX9MB5
It's only used for the error path in property parsing, so most of the time is
not useful.
Use the just-introduced NonCustomPropertyId::name to preserve the alias name,
which we were doing by passing the name around.
Bug: 1466645
Reviewed-by: xidorn
MozReview-Commit-ID: 46xxZKCoeBB
The six milliseconds spent in Olli's profile make me thing this is not getting
optimized and we expected.
Also move it to NonCustomPropertyId, so it works for aliases properly too.
Bug: 1466645
Reviewed-by: xidorn
MozReview-Commit-ID: 4d76Z55ZBEH
And make transition-property more correct by serializing --0 unescaped instead
of escaped.
Bug: 1466645
Reviewed-by: xidorn
MozReview-Commit-ID: CCBSe5Frd0d
This would cause properties to change the value semantics between, e.g.,
@keyframes and non-@keyframes, which would be observable.
It happens not to be observable since the animation-* and transition-*
properties are not allowed in @keyframes, nor have bits in `contain`, and none
of the two properties are allowed in @page. But I think it's the right thing to
do.
This still causes a quirk like a property value in chrome / user origins being
potentially different if the value is specified via CSS var functions. But I
think that is fine.
Bug: 1466136
Reviewed-by: hiro
MozReview-Commit-ID: GhoPt0I34oO
Though I think it may be slightly fishy if used in, e.g., a @keyframes block.
For our purposes right now it doesn't make a difference, I think.
Bug: 1466008
MozReview-Commit-ID: A7VCTOqaIuB
This removes some dubious font-family code too.
It ensures that vector longhands have a proper clone implementation
auto-generating it using `collect()`.
Bug: 1461296
Reviewed-by: xidorn
MozReview-Commit-ID: FkdnbTkeF6E
Prior to this change, if none of the fonts specified in CSS contained a
glyph for a codepoint, we tried only one fallback font. If that font
didn't contain the glyph, we'd give up.
With this change, we try multiple fonts in turn. The font names we try
differ across each platform, and based on the codepoint we're trying to
match. The current implementation is heavily inspired by the analogous
code in Gecko, but I've used to ucd lib to make it more readable,
whereas Gecko matches raw unicode ranges.
This fixes some of the issues reported in #17267, although colour emoji
support is not implemented.
== Notes on changes to WPT metadata ==
=== css/css-text/i18n/css3-text-line-break-opclns-* ===
A bunch of these have started failing on macos when they previously
passed.
These tests check that the browser automatically inserts line breaks
near certain characters that are classified as "opening and closing
punctuation". The idea is that if we have e.g. an opening parenthesis,
it does not make sense for it to appear at the end of a line box; it
should "stick" to the next character and go into the next line box.
Before this change, a lot of these codepoints rendered as a missing
glyph on Mac and Linux. In some cases, that meant that the test was
passing.
After this change, a bunch of these codepoints are now rendering glyphs
on Mac (but not Linux). In some cases, the test should continue to pass
where it previously did when rendering with the missing glyph.
However, it seems this has also exposed a layout bug. The "ref" div in
these tests contains a <br> element, and it seems that this, combined
with these punctuation characters, makes the spacing between glyphs ever
so slightly different to the "test" div. (Speculation: might be
something to do with shaping?)
Therefore I've had to mark a bunch of these tests failing on mac.
=== css/css-text/i18n/css3-text-line-break-baspglwj-* ===
Some of these previously passed on Mac due to a missing glyph. Now that
we're rendering the correct glyph, they are failing.
=== css/css-text/word-break/word-break-normal-bo-000.html ===
The characters now render correctly on Mac, and the test is passing. But
we do not find a suitable fallback font on Linux, so it is still failing
on that platform.
=== css/css-text/word-break/word-break-break-all-007.html ===
This was previously passing on Mac, but only because missing character
glyphs were rendered. Now that a fallback font is able to be found, it
(correctly) fails.
=== mozilla/tests/css/font_fallback_* ===
These are new tests added in this commit. 01 and 02 are marked failing
on Linux because the builders don't have the appropriate fonts installed
(that will be a follow-up).
Fix build errors from rebase
FontTemplateDescriptor can no longer just derive(Hash). We need to
implement it on each component part, because the components now
generally wrap floats, which do not impl Hash because of NaN. However in
this case we know that we won't have a NaN, so it is safe to manually
impl Hash.
This is the basic structure of the stuff. Following patches will fill
the gap between Gecko and Servo on value generating, and finally hook
it into InspectorUtils.
Bug: 1434130
Reviewed-by: emilio
MozReview-Commit-ID: KNLAfFBiY6e
Most of types just derive it using proc_macro directly. Some of value
types need manual impl.
In my current plan, this new trait will be used in bug 1434130 to expose
values as well.
Bug: 1455576
Reviewed-by: emilio
MozReview-Commit-ID: LI7fy45VkRw
