The current name reads to me like a boolean variable, even though it's
actually a counter. Try to make that property more explicit at its uses
by renaming it to something more evocative of counter-ness.
========
https://hg.mozilla.org/integration/gaia-central/rev/9c9b74319651
Author: gasolin <gasolin@gmail.com>
Desc: Merge pull request #29131 from gasolin/issue-1090799-5
Bug 1090799 - make nfc_handover_manager get bluetooth adapter via service query, r=ian, tauzen
========
https://hg.mozilla.org/integration/gaia-central/rev/a62afb1fe679
Author: gasolin <gasolin@gmail.com>
Desc: Bug 1090799 - make nfc_handover_manager get bluetooth adapter via service query & request, r=ian, tauzen
- wrap API specific difference in bluetooth.js
- wrap the difference interface of adapter.getPairedDevices API
- rap the difference callback of adapter.pair API
- use adapter.getConnectedDevices API instead of device.connected
- use promise resolve to get BTv1 adapter
- use service.query to detect if bluetooth is ready or not
- use service.request to get bluetooth adapter asynchronously
- cache adapter when bluetooth enabled and disabled
- use BaseModule's debug, rename `_debug` to `debug`
- fix test missusing mock_bluetooth.js instead of mock_navigator_moz_bluetooth
========
https://hg.mozilla.org/integration/gaia-central/rev/fbb9373bfe56
Author: GaryChen, PYChen <mmm198219@gmail.com>
Desc: Merge pull request #27766 from joshwalker1026/bug_1126709
Bug 1126709 - Should use the URL() object instead of string concatenation to resolve icon urls for Homescreen application. r=fabrice.
========
https://hg.mozilla.org/integration/gaia-central/rev/c841b03ac943
Author: Josh Cheng <joshwalker.cheng@gmail.com>
Desc: Bug 1126709 - Should use the URL() object instead of string concatenation to resolve icon urls for Homescreen application.
revise_test
========
https://hg.mozilla.org/integration/gaia-central/rev/c74fc72b9c87
Author: John Hu <johu@mozilla.com>
Desc: Revert "Merge pull request #29563 from huchengtw-moz/bug-1154642-context-menu-focus"
This reverts commit 7856cbd44e0c0c2164f3d0896f695645788b0b2f, reversing
changes made to e62169edf3010cce33bac5df48aa8a9c241ce736.
Since bug 960465 patch 14, we've retained finished transitions in order
to handle the issues described in
https://lists.w3.org/Archives/Public/www-style/2015Jan/0444.html . The
code that did this made the assumption that the transition manager is
notified of the full sequence of style changes that happen to an
element. However, when an element becomes part of a display:none
subtree and then later becomes displayed again, the transition manager
is not notified of a style change when it becomes displayed again (when
we do not have the old style context).
This patch introduces code to prune the finished transitions when that
happens.
This really fixes only part of the set of problems described in bug
1158431, which also affect running transitions. However, it's the part
of that set that was a regression from bug 960465, which introduced the
retention of finished transitions, and which makes these issues
substantially easier to hit.
I'd like to fix this part quickly because it's a regression and we
should backport the fix.
Without the patch, I confirmed that the following two tests fail:
INFO TEST-UNEXPECTED-FAIL | layout/style/test/test_transitions_dynamic_changes.html | bug 1144410 test - opacity after starting second transition - got 0, expected 1
INFO TEST-UNEXPECTED-FAIL | layout/style/test/test_transitions_dynamic_changes.html | bug 1144410 test - opacity during second transition - got 0, expected 0.5
With the patch, all the added tests pass.
--HG--
extra : transplant_source : %B4%A5%5Ck%E1%B7%F5Et%CF%9B%9F%40%97c%C5NM%D3%A8
This isn't spec'ed anywhere (since the whole Web Animations API <-> CSS
interaction isn't spec'ed yet) but it seems that changing animation-play-state
should not restart an idle animation.
If an author calls Cancel() on an animation then that animation should continue
to be idle until they call Play()/Pause() from the API. Cancelling an animation
and hanging on to it is a purely API-only feature and hence it's reasonable that
restoring it from this state is also an API-only feature.
One can imagine use-cases such as polyfilling where script wants to remove any
CSS Animations/Transitions run by the browser and replace them with something
else entirely. In that case, the script can call Cancel() on the animation and
be sure that the animation is going to stay out of the way even if something
else tweaks the animation-play-state.
This patch makes Cancel() call PostUpdate which clobbers certain state in style
so that animated style is correctly flushed when an animation is cancelled.
The main difficulty with this is that we *don't* want to call this when we're
cancelling an animation as a result of a style update or else we'll trigger
needless work. The pattern elsewhere has been to define a *FromStyle() method
for this case (e.g. CSSAnimation::PlayFromStyle, PauseFromStyle). This isn't
ideal because there's always the danger we will forget to call the appropriate
*FromStyle method. It is, however, consistent. Hopefully in bug 1151731 we'll
find a better way of expressing this.
