Bug 980558 - Enable extraWarnings on safe JS context (r=bholley)
Merge m-c to inbound
Bug 962140 Collect more details of the queue status when we removed unexpected char message from the queue r=jimm
Merge changes
Merge m-c to fx-team
Backed out changeset 263b6c86c1be (bug 980558) for build bustage on a CLOSED TREE
Bug 980558 - Enable extraWarnings on safe JS context (r=bholley)
Bug 978731 - Cursor position jumps around, dragging handles moves text, r=wesj
Bug 974197 - Fire MozAfterPaint after the compositor has composited the frame. r=roc
Bumping gaia.json for 2 gaia revision(s) a=gaia-bump

========

https://hg.mozilla.org/integration/gaia-central/rev/002f334d7698
Author: Kevin Grandon <kevingrandon@yahoo.com>
Desc: Merge pull request #16973 from KevinGrandon/bug_980653_email_dialog_header_line_height

Bug 980653 - Layout issues in email recipient action menu

========

https://hg.mozilla.org/integration/gaia-central/rev/dd29af39d721
Author: Kevin Grandon <kevingrandon@yahoo.com>
Desc: Bug 980653 - Layout issues in email recipient action menu r=asuth
Bumping manifests a=b2g-bump
Bug 979993 - Free the old input data in SetValueInternal. r=bz
Back out 965fe5b195ab (bug 962670) for leaking
Bumping gaia.json for 3 gaia revision(s) a=gaia-bump

========

https://hg.mozilla.org/integration/gaia-central/rev/09e4745e3b60
Author: Askeing Yen (fyen) <askeing@gmail.com>
Desc: Merge pull request #16162 from echangmoz/master

DS support in Settings -> data & cell; Settings -> SIM manager

========

https://hg.mozilla.org/integration/gaia-central/rev/2255ec675cb1
Author: Eric Chang <echang@mozilla.com>
Desc: Bug 972695 - [dsds] support Sim Manager in Settings on dsds phones

========

https://hg.mozilla.org/integration/gaia-central/rev/de10423400e1
Author: Eric Chang <echang@mozilla.com>
Desc: Bug 972695 - [dsds] support Sim Manager in Settings on dsds phone
Bumping manifests a=b2g-bump
Bug 965425 - expose ISO setting, r=dhylands,jst
Bug 980484 - make the zoom setting more robust, r=dhylands
Bug 979760 - Pull out a BeginTransaction call common to the start of all three branches of if/else logic.  r=mattwoodrow

I don't see any particular reason for them to logically be in each
branch, and it seems the code was originally written with the
BeginTransaction in one place, but later had to be refactored into its
current form.

Note that this separates the comment from one of the EndEmptyTransaction
calls below it, but the comment was actually associated primarily with
the further EndEmptyTransaction call, and with the if above it, based on
the history pointing to
https://hg.mozilla.org/mozilla-central/rev/b4e9a17e7fe2
Bug 979748 - Simplify code based on already having checked the NS_FRAME_OUT_OF_FLOW bit.  r=heycam

Since we've already returned if the NS_FRAME_OUT_OF_FLOW bit is not set,
and since FirstInFlow() is the same as this when GetPrevInFlow() is
null, this is a straightforward simplification of the code and should
not change behavior.
Bug 978712 - Prevent non-running transitions and animations (animations or transitions during their delay period, and animations after they finish) from repeatedly poking layer activity because we think we can run them on the compositor.  r=heycam

This changes the behavior of the CanPerformOnCompositorThread methods of
both ElementAnimations and ElementTransitions to check that the
respective animations or transitions are actually running.  This is ok
because:
 - The main caller is nsLayoutUtils::HasAnimationsForCompositor, and all
   of its callers pretty clearly want the more restricted behavior (they're
   concerned with layer activity)
 - The only other callers of these functions are
   nsAnimationManager::FlushAnimations and
   nsTransitionManager::FlushTransitions (determining when to do
   throttling), nsAnimationManager::GetAnimationsForCompositor (whose
   only caller,
   nsDisplayListBuilder::AddAnimationsAndTransitionsToLayer, also checks
   IsRunningAt).  I think these also all want or are fine with having
   the IsRunningAt check.

As to the actual changes:
 - In the animation manager, I think it's a mistake that
   ElementAnimation::IsRunningAt didn't already check
   mIterationDuration, since we throw out animations with a bad
   iteration-duration in ElementAnimations::EnsureStyleRuleFor.  So this
   makes that change as well.
 - In the transition manager, IsRunningAt already checks
   !IsRemovedSentinel().

I've confirmed in gdb on a device that this fixes the repeated
nsIFrame::SchedulePaint calls that were the symptom of this bug.

I believe this patch also makes it so that a short animation of a
property that can't be animated on the compositor doesn't prevent the
entire duration of the animation of a property that can from being
throttled (having the main thread style updates suppressed).