This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: EuRsDue63tK
--HG--
extra : rebase_source : 3356d4b80ff6213935192e87cdbc9103fec6084c
In addition to the sourceMappingURL comment, there is a second special
comment, "sourceURL", that can be used to set the "display name" of a
style sheet for developer tools. This name is also used as the base
URL for the source-map URL resolution algorithm. sourceURL is
described here:
https://blog.getfirebug.com/2009/08/11/give-your-eval-a-name-with-sourceurl/
This patch changes Firefox to record this URL, if specified, and to
expose it (chrome-only) vai StyleSheet.webidl.
MozReview-Commit-ID: 7NwXsOf7nbY
--HG--
extra : rebase_source : bd5d25b4d44f5f220a4624db346edbc4236c9886
This changes the CSS lexer to extract sourceMappingURL directives from
comments and preserve them; then changes the parser to expose this value
as the style sheet's sourceMapURL.
MozReview-Commit-ID: LfMamJ1PsU0
--HG--
extra : rebase_source : 258827720282d415f97f1d49d870b7c2448d39f4
The main change is that once we discover we have a bad-url-token we consume
everything up to, but not including, the next ')' character. While we do this
we can cross line boundaries and don't bother about matching braces or quotes.
We just keep going until we find the ')' or hit EOF.
The bulk of this commit was generated by running:
run-clang-tidy.py \
-checks='-*,llvm-namespace-comment' \
-header-filter=^/.../mozilla-central/.* \
-fix
This adds CSS parser error reporting for parsing of custom properties
and normal properties that have variable references.
When re-parsing a normal property that had a variable reference, we
report any parse error to be at the beginning of the property value.
This is because it is difficult to keep track of where exactly each
variable substitution came from to point to the particular value
that would have caused the parse error. For example, with this:
:root {
var-a: 1px 2px;
var-b: 3px var(a);
}
p {
margin: var(a) var(b);
}
we would end up resolving the value of 'margin' to:
" 1px 2px 3px 1px 2px"
In this string, the parse error occurs when we encounter the final
"2px", but by this point we don't know where that value came from.
So instead we just point to the line on which 'margin' was declared.
We extend ErrorReporter with an OutputError overload that takes the
specific line and column number to use in the error report to get this
right, and we store the line and column number for each token stream
we parse on the nsCSSValueTokenStream object.
This adds functions to nsCSSParser and nsCSSScanner that let us save the
current input position (and corresponding information like line/column
number) and parser pushback, and be able to restore it later. We'll use
this when rewinding the scanner after we first encounter a property with
a variable reference and go back to reparse it as a token stream.
This is the first part of handling variable references in regular
properties. We have the scanner set a flag whenever it returns a "var("
token, so that when we come to the end of parsing a property that
failed, we know that it is because of a variable reference.
We add a new class CSSVariableResolver whose job is to take the
inherited computed variables and the specified variable declarations and
to perform cycle removal and resolution of the variables, storing the
result in the CSSVariableValues object on an nsStyleVariables. We use
CSSVariableResolver in nsRuleNode::ComputeVariablesData.
The variable resolver does this:
1. Asks the CSSVariableValues and CSSVariableDeclarations objects
to add their variables to it.
2. Calls in to a new nsCSSParser function
EnumerateVariableReferences that informs the resolver which
other variables a given variable references, and by doing so,
builds a graph of variable dependencies.
3. Removes variables involved in cyclic references using Tarjan's
strongly connected component algorithm, setting those variables
to have an invalid value.
4. Calls in to a new nsCSSParser function ResolveVariableValue
to resolve the remaining valid variables by substituting variable
references.
We extend nsCSSParser::ParseValueWithVariables to take a callback
function to be invoked when encountering a variable reference. This
lets EnumerateVariableReferences re-use ParseValueWithVariables.
CSSParserImpl::ResolveValueWithVariableReferences needs different
error handling behaviour from ParseValueWithVariables, so we don't
re-use it.
CSSParserImpl::AppendImpliedEOFCharacters is used to take the
value returned from nsCSSScanner::GetImpliedEOFCharacters while
resolving variable references that were declared using custom
properties that encountered EOF before being closed properly.
The SeparatorRequiredBetweenTokens helper function in nsCSSParser.cpp
implements the serialization rules in CSS Syntax Module Level 3:
https://dvcs.w3.org/hg/csswg/raw-file/3479cdefc59a/css-syntax/Overview.html#serialization
This adds an enum to nsCSSScanner.h that represents the types of tokens
we need to consider when pasting together two adjacent tokens during
serialization or variable resolution. For example with:
var-a:orange;
var-b:red;
color:var(a)var(b);
we need to generate the string "orange/**/red" to parse for the value of
'color'.