a03d304acdb37dbd7b1bf4d5b5267f2fbace336d: Bug 1157754 part 1. Add a way to "catch" an ErrorResult, and a way to safely convert an ErrorResult to an nsresult. r=peterv
Boris Zbarsky <bzbarsky@mit.edu> - Sun, 26 Apr 2015 22:38:17 -0400 - rev 241086
Push 59028 by bzbarsky@mozilla.com at Mon, 27 Apr 2015 02:39:28 +0000
Bug 1157754 part 1. Add a way to "catch" an ErrorResult, and a way to safely convert an ErrorResult to an nsresult. r=peterv
eff50867d7e130353d72c6074ff69a10c9d5a188: Bug 1144410 - Remove finished transitions when a frame transitions away from being display:none. r=birtles
L. David Baron <dbaron@dbaron.org> - Sun, 26 Apr 2015 19:20:19 -0700 - rev 241085
Push 59027 by dbaron@mozilla.com at Mon, 27 Apr 2015 02:21:12 +0000
Bug 1144410 - Remove finished transitions when a frame transitions away from being display:none. r=birtles 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.
93ed74d675a51cc3d3a0baf4d6299dbea3561d84: Bug 1157989 part 4 - Make method comment style consistent; r=jwatt
Brian Birtles <birtles@gmail.com> - Mon, 27 Apr 2015 10:05:47 +0900 - rev 241084
Push 59026 by bbirtles@mozilla.com at Mon, 27 Apr 2015 01:07:04 +0000
Bug 1157989 part 4 - Make method comment style consistent; r=jwatt
dd8d8298b4a73200dfa224020bfac8e958eb5c81: Bug 1157989 part 3 - Make LimitBehavior enum a scoped enum; r=jwatt
Brian Birtles <birtles@gmail.com> - Mon, 27 Apr 2015 10:05:47 +0900 - rev 241083
Push 59026 by bbirtles@mozilla.com at Mon, 27 Apr 2015 01:07:04 +0000
Bug 1157989 part 3 - Make LimitBehavior enum a scoped enum; r=jwatt
c0931dce5e1210a4728f35a12ce154d9991c2b56: Bug 1157989 part 2 - Make Silently* methods protected; r=jwatt
Brian Birtles <birtles@gmail.com> - Mon, 27 Apr 2015 10:05:46 +0900 - rev 241082
Push 59026 by bbirtles@mozilla.com at Mon, 27 Apr 2015 01:07:04 +0000
Bug 1157989 part 2 - Make Silently* methods protected; r=jwatt These methods aren't part of the public API.
c583165edf38ba22abec607767c76a9cb9643a9c: Bug 1157989 part 1 - Line up methods in dom/animation/Animation with the API; r=jwatt
Brian Birtles <birtles@gmail.com> - Mon, 27 Apr 2015 10:05:46 +0900 - rev 241081
Push 59026 by bbirtles@mozilla.com at Mon, 27 Apr 2015 01:07:04 +0000
Bug 1157989 part 1 - Line up methods in dom/animation/Animation with the API; r=jwatt
5f00adf8395aba1e72aaecb930094ebc996da9d4: Bug 1157111 - Remove comment from SilentlySetCurrentTime; r=jwatt
Brian Birtles <birtles@gmail.com> - Mon, 27 Apr 2015 08:53:19 +0900 - rev 241080
Push 59025 by bbirtles@mozilla.com at Sun, 26 Apr 2015 23:53:48 +0000
Bug 1157111 - Remove comment from SilentlySetCurrentTime; r=jwatt The commented-out step has now been removed from the spec: https://github.com/w3c/web-animations/commit/34c2bc927250f6d90098d50fd5a0aac885f98109
f66f164d3160cc9618a3a328947414ce9f598f74: Bug 1150807 part 5 - Tests for Animation.cancel(); r=jwatt
Brian Birtles <birtles@gmail.com> - Mon, 27 Apr 2015 08:53:19 +0900 - rev 241079
Push 59025 by bbirtles@mozilla.com at Sun, 26 Apr 2015 23:53:48 +0000
Bug 1150807 part 5 - Tests for Animation.cancel(); r=jwatt
064e704dfa02c08995a4d4256291dd5eefe3fb18: Bug 1150807 part 4 - Don't play/pause an idle animation when animation-play-state changes; r=jwatt
Brian Birtles <birtles@gmail.com> - Mon, 27 Apr 2015 08:53:19 +0900 - rev 241078
Push 59025 by bbirtles@mozilla.com at Sun, 26 Apr 2015 23:53:48 +0000
Bug 1150807 part 4 - Don't play/pause an idle animation when animation-play-state changes; r=jwatt 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.
12421d0f1bb3e621f9040d63f566b3d9dc77dcce: Bug 1150807 part 3 - Call PostUpdate from Cancel; r=jwatt
Brian Birtles <birtles@gmail.com> - Mon, 27 Apr 2015 08:53:19 +0900 - rev 241077
Push 59025 by bbirtles@mozilla.com at Sun, 26 Apr 2015 23:53:48 +0000
Bug 1150807 part 3 - Call PostUpdate from Cancel; r=jwatt 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.
72571965f94d3fa4d9624ef06e765a80c1e3c1ce: Bug 1150807 part 2 - Expose Animation::Cancel in WebIDL; r=smaug
Brian Birtles <birtles@gmail.com> - Mon, 27 Apr 2015 08:53:18 +0900 - rev 241076
Push 59025 by bbirtles@mozilla.com at Sun, 26 Apr 2015 23:53:48 +0000
Bug 1150807 part 2 - Expose Animation::Cancel in WebIDL; r=smaug
076fabe36fd3d545b0b1df534a2b0e4ff0475960: Bug 1150807 part 1 - Fix SilentlySetCurrentTime to not set the start time when it is unresolved; r=jwatt
Brian Birtles <birtles@gmail.com> - Mon, 27 Apr 2015 08:53:18 +0900 - rev 241075
Push 59025 by bbirtles@mozilla.com at Sun, 26 Apr 2015 23:53:48 +0000
Bug 1150807 part 1 - Fix SilentlySetCurrentTime to not set the start time when it is unresolved; r=jwatt The reasoning for this change is described here: https://lists.w3.org/Archives/Public/public-fx/2015AprJun/0027.html Furthermore, subsequent tests introduced in this bug for the animation playState depend on this change.
d3fd099cb346d37fee0224fa91da8ac03da285c8: Bug 1095517 - Increase the timeout of browser_identity_UI.js
Ehsan Akhgari <ehsan@mozilla.com> - Sun, 26 Apr 2015 17:27:18 -0400 - rev 241074
Push 59024 by eakhgari@mozilla.com at Sun, 26 Apr 2015 21:29:39 +0000
Bug 1095517 - Increase the timeout of browser_identity_UI.js
7a669dc0384d3fbe561cd4caaf5c19b5a455ad35: Backout bug 1157276 because it broke the test on all platforms
Ehsan Akhgari <ehsan@mozilla.com> - Sun, 26 Apr 2015 17:25:56 -0400 - rev 241073
Push 59024 by eakhgari@mozilla.com at Sun, 26 Apr 2015 21:29:39 +0000
Backout bug 1157276 because it broke the test on all platforms
2a90e5ab58557b52a472db9b93b3f3022d057c0e: Bug 1157276, yield on mouse synthesize calls, r=test-only-change
Neil Deakin <neil@mozilla.com> - Sun, 26 Apr 2015 12:31:49 -0400 - rev 241072
Push 59023 by neil@mozilla.com at Sun, 26 Apr 2015 16:32:20 +0000
Bug 1157276, yield on mouse synthesize calls, r=test-only-change
bcdc6982ea80d7e3443b0d80fe8d3089a120088c: Bug 1079617 - Increase the timeout of browser_test_new_window_from_content.js
Ehsan Akhgari <ehsan@mozilla.com> - Sun, 26 Apr 2015 11:50:06 -0400 - rev 241071
Push 59022 by eakhgari@mozilla.com at Sun, 26 Apr 2015 15:50:45 +0000
Bug 1079617 - Increase the timeout of browser_test_new_window_from_content.js
0dd11177cdc4b29cf3619ff09275f025456c8688: Bug 865222 - Add MOZ_GUARD_OBJECT_NOTIFIER_PARAM to JSAutoCompartment and JSAutoNullableCompartment; r=efaust
Kyle Machulis <kyle@nonpolynomial.com> - Sun, 26 Apr 2015 08:49:03 -0700 - rev 241070
Push 59021 by kmachulis@mozilla.com at Sun, 26 Apr 2015 15:49:18 +0000
Bug 865222 - Add MOZ_GUARD_OBJECT_NOTIFIER_PARAM to JSAutoCompartment and JSAutoNullableCompartment; r=efaust
c8f9adecb1bc68c3d08c50fb6b324b13092e603e: Bug 1125205 - Display console API messages from shared or service workers to the web console, r=past
Andrea Marchesini <amarchesini@mozilla.com> - Sun, 26 Apr 2015 09:37:59 +0100 - rev 241069
Push 59020 by amarchesini@mozilla.com at Sun, 26 Apr 2015 08:38:22 +0000
Bug 1125205 - Display console API messages from shared or service workers to the web console, r=past
7293938ab6be8251cd8a959095fc2844591d3670: Bug 1158544 - Remove FTPChannelChild::mWasOpened and make the base class mWasOpened protected; r=mcmanus
Ehsan Akhgari <ehsan@mozilla.com> - Sat, 25 Apr 2015 09:58:53 -0400 - rev 241068
Push 59019 by eakhgari@mozilla.com at Sat, 25 Apr 2015 22:41:50 +0000
Bug 1158544 - Remove FTPChannelChild::mWasOpened and make the base class mWasOpened protected; r=mcmanus There is no need to have two separate variables for the same thing in the same object.
a1da50757074e51f632a5fb0aed2a4fb3e8db038: Bug 1158543 - Remove SpdyConnectTransaction::mRequestHead and make the base class mRequestHead protected; r=mcmanus
Ehsan Akhgari <ehsan@mozilla.com> - Sat, 25 Apr 2015 09:52:51 -0400 - rev 241067
Push 59019 by eakhgari@mozilla.com at Sat, 25 Apr 2015 22:41:50 +0000
Bug 1158543 - Remove SpdyConnectTransaction::mRequestHead and make the base class mRequestHead protected; r=mcmanus There is no need to have two separate variables for the same thing in the same object.
(0) -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 tip