2534ceef7946c4fb5c04601f87b8624c03e8de3b: Bug 1088637 - check we get the right transition event, r=Enn
Gijs Kruitbosch <gijskruitbosch@gmail.com> - Mon, 17 Aug 2015 13:43:28 +0100 - rev 258014
Push 29240 by kwierso@gmail.com at Mon, 17 Aug 2015 23:54:24 +0000
Bug 1088637 - check we get the right transition event, r=Enn
5d4ae7b9e9d39ca80121bbd5864694dfa61db8dd: Bug 1193788 - Remove unused variables from performance.dtd. r=jsantell
Lin Clark <lin.w.clark@gmail.com> - Mon, 17 Aug 2015 11:33:54 -0400 - rev 258013
Push 29240 by kwierso@gmail.com at Mon, 17 Aug 2015 23:54:24 +0000
Bug 1193788 - Remove unused variables from performance.dtd. r=jsantell
cc3c25bf13e2ea026e336e3eab941f18348d8208: Bug 1193023 - Intermittent fix, be more lenient on tick count for framerate actor tests. r=vp
Jordan Santell <jsantell@mozilla.com> - Sun, 16 Aug 2015 14:06:04 -0400 - rev 258012
Push 29240 by kwierso@gmail.com at Mon, 17 Aug 2015 23:54:24 +0000
Bug 1193023 - Intermittent fix, be more lenient on tick count for framerate actor tests. r=vp
6abcc952af87a3bb7e7954e31ce9b5a186daa799: Bug 1194962 - Removing border-radius from identity box. r=dao
Kalpesh Krishna <kalpeshk2011@gmail.com> - Mon, 17 Aug 2015 15:52:19 +0200 - rev 258011
Push 29240 by kwierso@gmail.com at Mon, 17 Aug 2015 23:54:24 +0000
Bug 1194962 - Removing border-radius from identity box. r=dao
7500607479f1fcba20b7addcb95e60ea607d707d: Bug 1182102 - Stop setting the bookmark-item class on the home button or the bookmarks button when moving them to the bookmarks toolbar. r=gijs
Dão Gottwald <dao@mozilla.com> - Mon, 17 Aug 2015 15:51:22 +0200 - rev 258010
Push 29240 by kwierso@gmail.com at Mon, 17 Aug 2015 23:54:24 +0000
Bug 1182102 - Stop setting the bookmark-item class on the home button or the bookmarks button when moving them to the bookmarks toolbar. r=gijs
9b980b4f4358c1e15fa08082cdc67c5fea940ae3: Merge m-c to fx-team. a=merge
Ryan VanderMeulen <ryanvm@gmail.com> - Mon, 17 Aug 2015 09:12:57 -0400 - rev 258009
Push 29240 by kwierso@gmail.com at Mon, 17 Aug 2015 23:54:24 +0000
Merge m-c to fx-team. a=merge
4cde80b886d2bd9fbaca9c5e72305791f037bd53: Bug 1169563 - 1 - Minor ESLint code cleanup; r=ednapiranha
Patrick Brosset <pbrosset@mozilla.com> - Thu, 13 Aug 2015 14:07:51 +0200 - rev 258008
Push 29240 by kwierso@gmail.com at Mon, 17 Aug 2015 23:54:24 +0000
Bug 1169563 - 1 - Minor ESLint code cleanup; r=ednapiranha
9673c75864beafca2f6c8b117b98503128bf2e56: Bug 1195474 - Annotate 759249-1.html and 415394-1.xhtml as asserting in e10s mode. a=me
Ryan VanderMeulen <ryanvm@gmail.com> - Mon, 17 Aug 2015 15:48:20 -0400 - rev 258007
Push 29239 by ryanvm@gmail.com at Mon, 17 Aug 2015 19:50:09 +0000
Bug 1195474 - Annotate 759249-1.html and 415394-1.xhtml as asserting in e10s mode. a=me
b3be345ec4d35949c9780af39840f466f705300b: Bug 1195472 - Annotate 505912-1.html to expect one assertion in e10s mode.
Ryan VanderMeulen <ryanvm@gmail.com> - Mon, 17 Aug 2015 15:36:20 -0400 - rev 258006
Push 29239 by ryanvm@gmail.com at Mon, 17 Aug 2015 19:50:09 +0000
Bug 1195472 - Annotate 505912-1.html to expect one assertion in e10s mode.
a6eeb28458fd2652e12e57334f046b7776d75bb4: Merge inbound to m-c. a=merge
Ryan VanderMeulen <ryanvm@gmail.com> - Mon, 17 Aug 2015 09:06:59 -0400 - rev 258005
Push 29238 by ryanvm@gmail.com at Mon, 17 Aug 2015 13:06:57 +0000
Merge inbound to m-c. a=merge
3bbd0d9291280d02bac1ed2e73298bc67b70cbda: Bug 1178834: IonMonkey - Always lazy link code, r=jandem
Hannes Verschore <hv1989@gmail.com> - Fri, 14 Aug 2015 17:57:57 +0200 - rev 258004
Push 29238 by ryanvm@gmail.com at Mon, 17 Aug 2015 13:06:57 +0000
Bug 1178834: IonMonkey - Always lazy link code, r=jandem
2526fbcbe37a5eae117ce258e8a872a7f8ae4830: Revert "Bug 1190970: [MSE] P1. Enable WebM by default on platforms not supporting h264/aac. r=cpeterson"
Jean-Yves Avenard <jyavenard@mozilla.com> - Mon, 17 Aug 2015 17:54:41 +1000 - rev 258003
Push 29238 by ryanvm@gmail.com at Mon, 17 Aug 2015 13:06:57 +0000
Revert "Bug 1190970: [MSE] P1. Enable WebM by default on platforms not supporting h264/aac. r=cpeterson" This reverts commit d05f091bf4d8#l1.25
2eddf957653d6d1a790ac681a8d86282295e4526: Bug 1188251 part 8 - Remove call to Animation::Tick from CheckAnimationRule; r=dholbert
Brian Birtles <birtles@gmail.com> - Mon, 17 Aug 2015 13:59:45 +0900 - rev 258002
Push 29238 by ryanvm@gmail.com at Mon, 17 Aug 2015 13:06:57 +0000
Bug 1188251 part 8 - Remove call to Animation::Tick from CheckAnimationRule; r=dholbert We want to move the newly-introduced RequestRestyle call from FlushAnimations to Animation::Tick. However, nsAnimationManager::CheckAnimationRule calls Animation::Tick so this would cause us to start posting animation restyles within a restyle. Typically, Animations have an effect (currently there is only one type of effect: KeyframeEffectReadOnly) and when there is any change in timing they pass it down to their effect. However, the Animation is dependent on the duration of the effect for determining if it is "finished" or not. As a result, when an effect's timing changes, the owning Animation needs to know. (The way this *should* work is that effects should tell their animation or trigger some chain of events that causes animation's to update themselves. However, the current implementation of effects is fairly primitive and does not do this or even have a reference to the owning Animation. When we implement the script API for updating the timing properties of effects we will have to fix this but for now it is up to code in layout/style to update the Animation when it touches the corresponding effect's timing.) nsAnimationManager::CheckAnimationRule currently does this by calling Animation::Tick() which ensures the Animation's finished state is updated accordingly. Ultimately we want to ensure that Animation::Tick is called exactly once per frame (and at the appropriate point in that frame) so we'd like to remove this call from CheckAnimationRule. This patch achieves that by: * Making Animation::SetEffect update the animation's timing - this is necessary for animations that are created by CheckAnimationRule and will be necessary when once we make Animation.effect writeable from script anyway. * Calling Animation::SetEffect even for the case when we are updating the existing effect. Another side-effect of calling Animation::Tick within nsAnimationManager::CheckAnimationRule is that CSSAnimation::Tick queues events. There are some tests (e.g. layout/style/test/test_animations.html) that assume that animationstart events are dispatched immediately when new animations are created. That will change with bug 1134163 but for now we should maintain this existing behavior since changing this might introduce compatibility issues that are best dealt with as a separate bug rather than blocking this refactoring. To that end, this patch also explicitly queues animationstart events for newly-created animations.
2be8060a496921b76fad7c48c47bf4ff195d6401: Bug 1188251 part 7 - Move WillRefresh to CommonAnimationManager; r=dholbert
Brian Birtles <birtles@gmail.com> - Mon, 17 Aug 2015 13:59:44 +0900 - rev 258001
Push 29238 by ryanvm@gmail.com at Mon, 17 Aug 2015 13:06:57 +0000
Bug 1188251 part 7 - Move WillRefresh to CommonAnimationManager; r=dholbert nsTransitionManager::WillRefresh and nsAnimationManager::WillRefresh are now identical and all methods they call exist on CommonAnimationManager so we can unify them there.
8cbb80c89aefa630ac067191b17d5e2a67bb43d2: Bug 1188251 part 6 - Unify FlushAnimations and FlushTransitions; r=dholbert
Brian Birtles <birtles@gmail.com> - Mon, 17 Aug 2015 13:59:44 +0900 - rev 258000
Push 29238 by ryanvm@gmail.com at Mon, 17 Aug 2015 13:06:57 +0000
Bug 1188251 part 6 - Unify FlushAnimations and FlushTransitions; r=dholbert The implementations of FlushAnimations and FlushTransitions should now be all but equivalent so this patch combines them into a single implementation on CommonAnimationManager. Regarding some of the minor differences between the two methods: * The combined implementation drops the check for an empty list of collections found only in FlushTransitions. This seems like a very minor optimization that could possibly cause us to fail to unregister from the refresh driver if we forgot to do so when removing the last collection. * The combined implementation uses the loop implementation from FlushAnimations since it is more compact. This patch also removes the extra nested scope since it doesn't seem necessary.
754717f00c5e1f31fde952cd96a0680c20b7c64e: Bug 1188251 part 5 - Move some assertions from FlushTransitions to RequestRestyle; r=dholbert
Brian Birtles <birtles@gmail.com> - Mon, 17 Aug 2015 13:59:44 +0900 - rev 257999
Push 29238 by ryanvm@gmail.com at Mon, 17 Aug 2015 13:06:57 +0000
Bug 1188251 part 5 - Move some assertions from FlushTransitions to RequestRestyle; r=dholbert There are a couple of assertions that only exist in FlushTransitions (and not FlushAnimations). This patch moves them to RequestRestyle since they appear to apply to either transitions or animations equally. By eliminating this difference between FlushTransitions and FlushAnimations we should then be in a position to combine them into a common method on the base class.
ae2c4fad97a0b41f71364091cfe1cfc9dbd9eae3: Bug 1188251 part 4 - Move throttling checks to AnimationCollection::RequestRestyle; r=dholbert
Brian Birtles <birtles@gmail.com> - Mon, 17 Aug 2015 13:59:44 +0900 - rev 257998
Push 29238 by ryanvm@gmail.com at Mon, 17 Aug 2015 13:06:57 +0000
Bug 1188251 part 4 - Move throttling checks to AnimationCollection::RequestRestyle; r=dholbert This patch moves the additional checks (beyond those of Animation::CanThrottle) from FlushAnimations/FlushTransitions to AnimationCollection::RequestRestyle. These checks are on a per-collection basis hence it makes sense for the collection to perform them. This also moves logic out of the managers which is needed if we want to support script-based animations without introducing another manager.
eb67f47a146dc79c39cbffab9e522288901be911: Bug 1188251 part 3 - Add AnimationCollection::RequestRestyle; r=dholbert
Brian Birtles <birtles@gmail.com> - Mon, 17 Aug 2015 13:59:44 +0900 - rev 257997
Push 29238 by ryanvm@gmail.com at Mon, 17 Aug 2015 13:06:57 +0000
Bug 1188251 part 3 - Add AnimationCollection::RequestRestyle; r=dholbert Ultimately we want to move throttling logic to AnimationCollection and Animation::Tick (and later to KeyframeEffect::SetParentTime). This is so that we can support script-generated animations without having to introduce yet another manager. To that end this patch introduces a method on AnimationCollection that can be called from Animation::Tick to perform the necessary notifications needed to update style. Later in this patch series we will extend RequestRestyle to incorporate more of the throttling logic and further extend it to cover some of the other notifications such as updating layers. This patch tracks whether or not we have already posted a restyle for animation to avoid making redundant calls. Calls to nsIDocument::SetNeedStyleFlush are cheap and more difficult to detect when they have completed so we don't filter redundant calls in the Restyle::Throttled case. If mHasPendingAnimationRestyle is set and AnimationCommon::EnsureStyleRuleFor is *never* called then we could arrive at situation where we fail to make post further restyles for animation. I have verified that if we fail to reset mHasPendingAnimationRestyle at the appropriate point (e.g. resetting it at the end of EnsureStyleRuleFor *after* the early-returns) then a number of existing tests fail. Furthermore, I have observed that it is reset by the beginning of each tick in almost every case except for a few instances of browser mochitests such as browser/components/customizableui/test/browser_1007336_lwthemes_in_customize_mode.js. In this case, during the async cleanup of the test, we have an opacity transition on a vbox element that becomes display:none and appears to be skipped during restyling. However, even in this case, EnsureStyleRuleFor is called within one or at most two ticks and mHasPendingAnimationRestyle flag is cleared (i.e. it does not get stuck).
6bb23d47f4694dc552469db17a3db180e266d3e9: Bug 1188251 part 2 - Check if a tick can be throttled in FlushAnimations using Animation::CanThrottle; r=dholbert
Brian Birtles <birtles@gmail.com> - Mon, 17 Aug 2015 13:59:44 +0900 - rev 257996
Push 29238 by ryanvm@gmail.com at Mon, 17 Aug 2015 13:06:57 +0000
Bug 1188251 part 2 - Check if a tick can be throttled in FlushAnimations using Animation::CanThrottle; r=dholbert In FlushTransitions and FlushAnimations we use different mechanisms to see if a transition/animation can be throttled on the current tick. FlushTransitions calls Animation::CanThrottle whilst FlushAnimations calls EnsureStyleRuleFor and checks if the rule has changed or not. These are not as completely different as they might seem at first since, internally, EnsureStyleRuleFor calls Animation::CanThrottle. We would like to unify this behavior and simply use Animation::CanThrottle in FlushAnimations as we do in FlushTransitions. First, however, we have to account for the differences in these approaches: 1. Using the result of EnsureStyleRuleFor means we may *not* call PostRestyleForAnimation if an animation collection's mNeedsRefreshes member is false. This member is false when all animations have finished (or there are no animations in the collection). In this case EnsureStyleRuleFor will not update the style rule and we will end up assuming the tick can be throttled. *However*, in the case that all animations are finished Animation::CanThrottle will *also* return true (technically it will return false until we compose style for the first time after becoming finished but beyond that one moment it will return true) so skipping this check by using Animation::CanThrottle instead of EnsureStyleRuleFor should not make a significant difference. 2. Using the result of EnsureStyleRuleFor will mean that if we have already updated the style rule within a given tick we will avoid calling PostRestyleForAnimation (and call SetNeedStyleFlush instead). This can happen the first time we call FlushAnimations from PresShell::FlushPendingNotifications. (When we call FlushAnimations from nsAnimationManager::WillRefresh mStyleRuleRefreshTime will be stale and we won't apply this optimization. Furthermore after the first call to PresShell::FlushPendingNotifications we will typically skip calling FlushAnimations since PresShell::StyleUpdateForAllAnimationsIsUpToDate will typically return true). This seems like a possibly useful optimization although it is surprising we don't do the same for transitions. Note that this optimization applies regardless of whether we are performing a throttleable flush or not. That is, even if we pass CommonAnimationManager::Cannot_Throttle we will still end up throttling the tick in this case. Furthermore, we will mark the document as needing a style flush even though this does not appear to be necessary. This patch copies this optimization (checking if mStyleRuleRefreshTime) to FlushAnimations so we can maintain this behavior when calling Animation::CanThrottle instead of EnsureStyleRuleFor. It also applies the same behavior to FlushTransitions for consistency (and so we can later combine FlushAnimations and FlushTransitions). Note that we apply this optimization *before* calling Tick since it should only apply once we have already Tick'ed the animations in the collection. We will first hit FlushAnimations as a result of the refresh driver calling nsAnimationManager/nsTransitionManager::WillRefresh at which point mStyleRuleRefreshTime should be stale. Using this order not only saves redundant work but also makes moving the restyle code to Animation later on more straightforward. (In future we will divorce WillRefresh and FlushAnimations and only call Tick in WillRefresh and only perform this optimization FlushAnimations.) 3. Using the result of EnsureStyleRuleFor means that while checking if we can throttle or not we also update the style rule in FlushAnimations. That seems like an odd side-effect particularly since FlushTransitions doesn't do the same thing.
0924d8ec4bd78dacd5f01970fb9a2941fbe66cf8: Bug 1188251 part 1 - Remove transitions cleanup from FlushTransitions; r=dholbert
Brian Birtles <birtles@gmail.com> - Mon, 17 Aug 2015 13:59:44 +0900 - rev 257995
Push 29238 by ryanvm@gmail.com at Mon, 17 Aug 2015 13:06:57 +0000
Bug 1188251 part 1 - Remove transitions cleanup from FlushTransitions; r=dholbert There is no longer anything in FlushTransitions that modifies the set of transitions. I believe this changed as of bug 960465, specifically changeset https://hg.mozilla.org/mozilla-central/rev/b2ee72589c18, so that this code is no longer needed. By removing this we can further align FlushAnimations and FlushTransitions.
(0) -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 tip