The logic around here is a bit tricky, because -moz-linear-gradient() shares
this codepath. Here's how things were going wrong:
* The -moz-linear-gradient syntax allows an angle (e.g. "30deg") to be followed
by an optional box-position (e.g. "top right") before eventually requiring a
comma and then some color stops.
* In contrast, the -webkit-linear-gradient syntax does NOT allow a box-position
there (unless the box-position is by itself, without an angle).
* So, for -webkit-linear-gradient, we (correctly) skipped the box-position
parsing code, if we've seen an angle already.
* BUT: in skipping that code, we *also* inadvertantly skipped the code that
enforces that we eventually see a comma before we get to the color stops.
So, we incorrectly accept some -webkit-linear-gradient() expressions that are
missing a comma that really should be mandatory.
So, this patch adds a special case for -webkit-linear-gradient that
preemptively bails if we get an angle that's not followed by a comma. (With
that, we can also simplify the condition around the box position parsing, too.)
MozReview-Commit-ID: B7MQLxqe6D7
Note: Instead of exactly honoring the legacy -webkit-gradient(linear,...)
syntax, we aim to simply parse it into something that's approximately
equivalent for common use cases.
In the legacy -webkit-gradient(linear,...) syntax, authors provide *two
arbitrary points* to establish the direction of the gradient, whereas modern
linear-gradient() is simpler: it just takes a single "<side-or-corner>" point
and fills the box with a gradient in the direction of that side or corner.
Before this changeset, we parsed -webkit-gradient(linear,...) into a
slightly-less-legacy "-moz-linear-gradient" representation, so that we could
honor at least one of the author's specified points (since -moz-linear-gradient
accepts a single arbitrary point as the start of the gradient). But that
prevents us from deprecating -moz-linear-gradient, and it makes it impossible
to spec our emulation behavior in terms of modern standards.
So, this changeset is just changing our approximate representation so that it
can always be serializeable as a modern linear-gradient() expression.
In addition, I'm removing the reftest "webkit-gradient-approx-linear-1.html"
(whose behavior this patch is changing slightly) and I'm replacing it with a
new chunk in test_computed_style.html to more directly test this parsing
behaivor.
MozReview-Commit-ID: 6N1oKaGeOuE
This switches over from using nsStringBuffer to nsString for URLValueData's
|mString| member. This avoids various tedious conversions and can provide
potential performance improvements by avoiding length calculations.
MozReview-Commit-ID: 5eRifUZrAso
scrollbars.css is the only sheet which is parsed as author level, but later
added as agent level in [1]. Add a new enum value so that it can be parsed
as author level in gecko (nsCSSParser::AgentRulesEnabled() will exclude it),
but servo can recognize it as agent level sheet when the sheet is created.
Delete UserRulesEnabled() because no one uses it.
[1] http://searchfox.org/mozilla-central/rev/7419b368156a6efa24777b21b0e5706be89a9c2f/layout/base/nsDocumentViewer.cpp#2326
MozReview-Commit-ID: 2lrV4ogfnHM
This change is to use gecko_enum_prefix in helpers.mako.rs, so that we do not
need to manually write code for nsStyleDisplay::mTransformBox.
MozReview-Commit-ID: 7UAL0iUcSIO
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
Use eCSSUnit_Function to store the frames timing function. Also, add one more
css keyword: frames.
The following changes are included in this:
1. Parser changes.
2. Serialization.
3. Computation in nsRuleNode.
4. Invalid and other values in property_database.js
MozReview-Commit-ID: 887QcXHQ2pU
(GetAssociatedDocument was recently renamed in bug 1332353.)
Note that the inconsistency between the Rule and CSSParser method names
is slightly bothersome.
MozReview-Commit-ID: L1SBIV86H4s
nsCSSProps::FindKeyword() has always failed when passed eCSSKeyword_UNKNOWN,
but it didn't used to have a fast-path for this sentinel value -- it used to
walk the whole array before failing. So it used to make sense to have a
dedicated check for it at the callsites, to avoid an unnecessary array
traversal. But now, there's an early-return in FindKeyword() (or actually in
its helper, FindIndexOfKeyword()) which catches eCSSKeyword_UNKNOWN right away,
before it walks the array. So there's no benefit to having a dedicated check at
the callsites anymore.
MozReview-Commit-ID: FOX48YZMomd
