Bug 937317 - When invoking a callback object, restore the incumbent script settings object from when the callback was created. r=bz

See the 'incumbent script' stuff in the WebIDL spec.
Bug 937317 - Return null from ToWebIDLCallback if one doesn't already exist. r=bz
Bug 937317 - Replace all instance of null cx pushing with AutoSystemCaller. r=bz

This is an easy bonus chunk of the work to phase out cx pushing in the browser.
Bug 937317 - Remove unnecessary AutoSystemCaller usage. r=bz

See bug 937317 comment 38.
Bug 937317 - Root around GC call GetIncumbentGlobal. r=bz
Bug 937317 - Tests. r=bz
Bug 937317 - touch clobber file. r=me
Bug 948516 - Assert that js::HashTable pointers and enumerators are used correctly; r=luke
Bug 948782 - Make test_alerts_noobserve.html wait until its alerts have disappeared before finishing. r=wchen
Bug 909170 - Add some tests for @supports conditions with tokens after a declaration's priority. r=dbaron
Bug 773296 - Part 1: Add a preference for CSS variables. r=dbaron
Bug 773296 - Part 2: Parse CSS variable declarations and store them on Declaration objects. p=ebassi,heycam r=dbaron

Patch co-authored by Emmanuele Bassi <ebassi@gmail.com>

This defines a CSSVariableDeclarations class that holds a set of
variable declarations.  This is at the specified value stage, so values
can either be 'initial', 'inherit' or a token stream (which is what you
normally have).  The variables are stored in a hash table.  Although
it's a bit of a hack, we store 'initial' and 'inherit' using special
string values that can't be valid token streams (we use "!" and ";").

Declaration objects now can have two CSSVariableDeclarations objects
on them, to store normal and !important variable declarations.  So that
we keep preserving the order of declarations on the object, we inflate
mOrder to store uint32_ts, where values from eCSSProperty_COUNT onwards
represent custom properties.  mVariableOrder stores the names of the
variables corresponding to those entries in mOrder.

We also add a new nsCSSProperty value, eCSSPropertyExtra_variable, which
is used to represent any custom property name.
nsCSSProps::LookupProperty can return this value.

The changes to nsCSSParser are straightforward.  Custom properties
are parsed and checked for syntactic validity (e.g. "var(a,)" being
invalid) and stored on the Declaration.  We use nsCSSScanner's
recording ability to grab the unparsed CSS string corresponding to
the variable's value.
Bug 773296 - Part 3: Allow more than 27 style structs. r=dbaron

This bumps up nsStyleContext::mBits to a uint64_t so that it can fit
another style struct.  If we're going to need to keep at least 27 style
structs, it might be better to split mBits up into two uint32_ts: one
for the flags and one for the style struct bits.
Bug 773296 - Part 4: Add style struct to store CSS variables. r=dbaron

This adds an nsStyleVariables on which computed variable values
will be stored.  We don't actually have any properties assigned to
nsStyleVariables; eCSSPropertyExtra_Variables which we added earlier
isn't a real property.  To avoid compiler errors for gVariableFlags
being a zero length array, we stick a dummy entry in there.

nsRuleNode::ComputeVariablesData does nothing for the moment.

nsStyleVariable nsChangeHint calculations always return 0, as later
we will compare the actual properties that reference variables to
see what changes are required for them.
Bug 773296 - Part 5: Map variables on a Declaration to nsRuleData. r=dbaron

This adds a CSSVariableDeclarations object to nsRuleData and adds a
MapRuleInfoInto function to CSSVariableDeclarations so the can copy
variable declarations into a nsRuleData's object.  We call that from
Declaration::Map{Normal,Important}RuleInfoInto.

We make HasImportantData return true if we have important variables
but no important non-custom properties on a declaration, since that
is used to determine whether we have a rule node for important
declarations.  This means MapImportantRuleInfoInto can no longer
assume that mImportantData is non-null.
Bug 773296 - Part 6: Add enum to represent types of CSS tokens involved in serialization. r=dbaron

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'.
Bug 773296 - Part 7: Add a field to nsStyleVariables to store computed variable values. r=dbaron

This defines a class CSSVariableValues which is used to store
computed variable values.  We store them a bit differently from
CSSVariableDeclarations -- here we have a hash table of variable names
to integer IDs, and then an array of variables where the array index
is the ID.  This is because later on we'll want a stable order for the
variables to return from DOM APIs.

In addition to the string value of the variable, we store the type
of the first and last token of the variable value.  This information
will be used when resolving entire variable reference containing
values, to determine when to insert "/**/" before and after a resolved
var(blah) token.

We add a CSSVariableValues member to nsStyleVariables.
Bug 773296 - Part 8: Resolve and compute CSS variables. r=dbaron

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
Bug 773296 - Part 9: Give nsCSSScanner the ability to remember when it encounters a "var(" token. r=dbaron

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.
Bug 773296 - Part 10: Add a new eCSSUnit_TokenStream type for storing unparsed CSS values. p=ebassi,heycam r=dbaron

Patch co-authored by Emmanuele Bassi <ebassi@gmail.com>

This adds a new nsCSSValue unit type to represent an unparsed
stream of CSS tokens as a specified value.  This is what properties
that have a variable reference get as their specified value.

On the nsCSSValueTokenStream object that is used when mUnit ==
eCSSUnit_TokenStream, we store two property IDs: first, the property
ID for the longhand that this token stream value is the value for.  We
pass this back in to nsCSSParser::ParseProperty at computed value time,
when we need to re-parse the property.  Second is the shorthand property
ID, if we used a variable reference in a shorthand.  In such a case, we
store the token stream value for each of the corresponding longhand
properties.  This is because shorthands don't actually get any storage
in an nsRuleData, and because any of the longhands might be overwritten
by subsequent declarations, we need to keep the token stream somewhere.

We also store other information on the nsCSSValueTokenStream required by
the CSS parser (base URI, etc.).