========
https://hg.mozilla.org/integration/gaia-central/rev/d5d3a0d38906
Author: Ryan VanderMeulen <ryanvm@gmail.com>
Desc: Revert "Merge pull request #16831 from sergi/921971-fdn"
This reverts commit cdcc68168c8aaef12a8b4e9137fec83128e6afb9, reversing
changes made to 183c2e102105aa5bc804f7c9c36a840fe2266c52.
========
https://hg.mozilla.org/integration/gaia-central/rev/23df3aeef9e1
Author: Sergi Mansilla <sergi.mansilla@gmail.com>
Desc: Merge pull request #16831 from sergi/921971-fdn
Bug 921971 - [DSDS][FDN] Manage FDN list for both SIMs
========
https://hg.mozilla.org/integration/gaia-central/rev/fcd18131ccc6
Author: Sergi Mansilla <sergi@Sergis-MacBook-Pro.local>
Desc: Bug 921971 - [DSDS][FDN] Manage FDN list for both SIMs
This fix makes it possible to have independent Fixed Dialing Numbers for each
SIM card in the phone. A new function `getIccByIndex` has been introduced in
`utils.js` that selects the currently selected ICC object without the user
having to specify the particular index, although it allows that too (used in
`sim_dialog.js`, for example.
Instances of `IccHelper` have been replaced by the result of calls to
`getIccByIndex`.
========
https://hg.mozilla.org/integration/gaia-central/rev/63ec36329e28
Author: gasolin <gasolin@gmail.com>
Desc: Merge pull request #16808 from gasolin/issue-942724
Bug 942724 - Support multiple notifications for recording device status, r=alive
========
https://hg.mozilla.org/integration/gaia-central/rev/4c66c84da430
Author: gasolin <gasolin@gmail.com>
Desc: Bug 942724 - Support multiple notifications for recording device status
- refactor: using createItem function to return data dict
- abstract renderPanels
- fix and support recording status
- add test cases
- refactor use updateRecordingStatus
- update statusbar status via custom event
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).
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.
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
