========
https://hg.mozilla.org/integration/gaia-central/rev/9f88434e3a0e
Author: Yi-Fan Liao <begeeben@gmail.com>
Desc: Merge pull request #22387 from begeeben/1029944_switch_modaldialog_and_appmodaldialog
Bug 1029944 - Switch ModalDialog and AppModalDialog from using strings to using l10nIds, r= Zibi Braniecki [:gandalf]
* Replace mozL10n.get(l10nId) calls with node.setAttribute('data-l10n-id', l10nId) in ModalDialog and its use cases.
* Fix jshint errors.
* Update ModalDialog test.
========
https://hg.mozilla.org/integration/gaia-central/rev/032c743be685
Author: Yi-Fan Liao <begeeben@gmail.com>
Desc: Bug 1029944 - Switch ModalDialog and AppModalDialog from using strings to using l10nIds
* Replace mozL10n.get(l10nId) calls with node.setAttribute('data-l10n-id', l10nId) in ModalDialog and its use cases.
* Fix jshint errors.
* Update ModalDialog test.
The assertion in nsTimeStamp::operator >= occasionally fails due to a null RHS
timestamp when called from AnimationPlayer::GetCurrentTimeDuration, which, in
turn, is called from AnimationPlayer::SetSource.
The issue appears to be that we're not correctly initializing
AnimationPlayer.mPlayState. This value can be running (0) or paused (1) but we
only ever compare against the paused state (i.e. every other value is
effectively treated as running). If we don't initialize this we can end
up in the paused state but with mPauseStart not set to a valid (non-null)
TimeStamp. This creates an inconsistent state since we assume that when we're
paused mPauseStart is non-null, hence the assertion fails.
This gets tickled because, since bug 1040543, we call
AnimationPlayer::SetSource from nsAnimationManager::BuildAnimations *before* we
set mPlayState and mPauseStart.
This patch initializes mPlayState to the running state so we don't accidentally
end up in an inconsistent state.
It also removes some (now unnecessary) initialization of mPlayState and
mPauseStart from nsTransitionManager::ConsiderStartingTransition.
In future we could also consider reworking nsAnimationManager::BuildAnimations
so that we call SetSource on the new animation player *after* setting up its
play state. That may be more correct and would further avoid this problem but
may not be necessary since all that code is likely to change in the near future.
This commit fixes two bugs. When sending two notifications with the same
tag, the NotificationDB this.byTag member was not properly updated. This
resulted in multiple notifications with the same tag being saved.
NotificationStorage's cache may hide this during the running session,
but on B2G the resend of notifications at reboot would expose the issue.
The second bug fixed is the test that makes sure we properly overwrite
notifications with the same tag in the database: the way we handled fake
notification object made them sharing the same ID. This, NotificationDB
would not even consider the tags and this lead to hiding the bug.
