Fix merge error between bug 872273 (changeset 46df3fd9b0dc) and bug 946065 (changeset 243259fda9ab) and move this test to the directory where it's listed in mochitest.ini so it will actually be run.  No review.

Bug 979640 is filed on making this mistake harder.

--HG--
rename : content/xbl/test/test_bug872273.xhtml => dom/xbl/test/test_bug872273.xhtml
Bug 976777:  Truncate long source lines in script errors before sending them to the parent process.  r=bent

This fixes an out-of-memory foreground-tab crash that I could reliably
reproduce on a 256MB Firefox OS phone, and I think also significantly
reduces the number of background tabs I'm seeing killed due to low
memory.
Bug 621618 patch 1:  Remove BindToTree overrides in nsXMLElement that exist only to make AddToIdTable/RemoveFromIdTable calls already in the base class (Element).  r=bzbarsky

I think this could have been done as part of Bug 700981 part 2, which
moved AddToIdTable and RemoveFromIdTable calls from nsStyledElement to
nsGenericElement.
Bug 621618 patch 2:  Make nsXMLElement reuse Element::AddToIdTable and Element::RemoveFromIdTable thoroughly.  r=bzbarsky
Bug 621618 patch 3:  Add FIXMEs in nsXULDocument for ID handling.  r=bzbarsky
Bug 621618 patch 4:  Make conditions in Element::RemoveFromIdTable match those in AddToIdTable, to avoid asymmetric calls to the document's functions.  r=bzbarsky
Bug 978648:  Handle dynamic changes to @keyframes rules and keyframe rules better.  r=heycam
Bug 978903: Fix some uninitialized variable warnings in the CSS parser.  r=heycam

The first provides a reasonable default (failure to parse) for the case
of an unknown value type (which should never happen).

The second reorders two failure checks so that the one that returns
early when units is uninitialized happens before the one that looks at
units.
Bug 828173 patch 1:  Add nsLayoutUtils::GetReferenceFrame.  r=mattwoodrow
Bug 828173 patch 2:  Make Layer::AddAnimation have the caller fill in the data instead of taking parameters.  r=mattwoodrow

(This is a bigger simplification later in the patch queue, when I add a
variant of AddAnimation called AddAnimationForNextTransaction.)
Bug 828173 patch 3:  Add a concept of pending animations to Layer, like pending transform.  r=mattwoodrow
Bug 828173 patch 3.5:  Move GetTransformRootFrame to nsLayoutUtils.  r=mattwoodrow
Bug 828173 patch 4:  Expose AddAnimationsAndTransitionsToLayer and allow it to be called from style change handling.  r=mattwoodrow
Bug 828173 patch 5:  Call AddAnimationsAndTransitionsToLayer when we choose not to repaint when handling an UpdateTransformLayer hint, so that any new animations resulting from the style change get sent to the layer.  r=mattwoodrow
Bug 828173 patch 6:  Remove calls to ForceLayerRerendering from the miniflush code (UpdateThrottledStyles, which flushes animations whose main thread updates are throttled without updating any other styles).  r=mattwoodrow

I've been wanting to remove this code for a while.  I think this code is
problematic for three reasons:

 (1) It's in the middle of code where it doesn't belong, and which ought
     to be handling purely-style-system things.  (This is blocking me
     from reusing that code elsewhere, e.g., in bug 977991 and
     bug 960465, both of which could use it in some form.)

 (2) It defeats the optimization from bug 790505 whenever we do a
     miniflush (in other words, whenever we have any style change,
     whether or not it's related)

 (3) It means the conditions for when we decide to ship a new set of
     animation data to a layer doesn't cover all the cases the layer
     needs it.  In particular, we only run this miniflush code when we
     have a currently running animation or transition that's running on
     the compositor thread.  On the other hand, the UpdateTransformLayer
     style change handling in DoApplyRenderingChangeToTree depends on
     whether the frame currently has a transform layer, which can
     continue to be true for a bit after the animation stops.  So if we
     need to send animations to the layer because of a transform style
     change that happens soon after an animation completes, our style
     change handling will find the existing layer and call its
     SetBaseTransformForNextTransaction method but never do anything
     that triggers layer construction.  The style throttling code, in
     turn, will never stop doing main thread updates because the
     animation generation on the layer is out-of-date, and these main
     thread updates will keep the layer active, but they'll never show
     up because the stale animation data overrides the new transform
     that we've been setting.  (At least, I think that's what was
     happening; it makes sense to me and matches the behavior I was
     observing.  I didn't verify which main thread updates and which
     layer updates were actually happening, though.)

     This shows up, for example, in the animation in attachment 8384813
     just halting at a corner if I'm careful not to disturb it.  (I'm
     testing on Linux, with both accelerated layers and OMT animations
     explicitly enabled.)

I think there are probably some other things that can be removed as
followups to removing this code, because I think we made some boundary
conditions intentionally incorrect so that problem (3) above wouldn't be
as bad as it otherwise would have been.
Bug 979555:  Add default value for layers.offmainthreadcomposition.log-animations preference to all.js.  r=dzbarsky

It's good practice to have default values for all preferences in all.js.
Otherwise some preference APIs throw exceptions and/or leave values
uninitialized.  It also makes the preference show up in about:config.

Bug 875204 accidentally removed this line from all.js even though the
pref was not removed.  (The pref was initially added in bug 780342.)
Bug 979557:  CanAnimatePropertyOnCompositor should return early when there's no OMT compositing, whether or not logging is enabled.  r=dzbarsky

This shouldn't behave differently depending on whether or not logging is
enabled; that difference was introduced in bug 785648.