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 292314
Push 962 by jlund@mozilla.com at Fri, 04 Dec 2015 23:28:54 +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 292313
Push 962 by jlund@mozilla.com at Fri, 04 Dec 2015 23:28:54 +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 292312
Push 962 by jlund@mozilla.com at Fri, 04 Dec 2015 23:28:54 +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 292311
Push 962 by jlund@mozilla.com at Fri, 04 Dec 2015 23:28:54 +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 292310
Push 962 by jlund@mozilla.com at Fri, 04 Dec 2015 23:28:54 +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 292309
Push 962 by jlund@mozilla.com at Fri, 04 Dec 2015 23:28:54 +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 292308
Push 962 by jlund@mozilla.com at Fri, 04 Dec 2015 23:28:54 +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 292307
Push 962 by jlund@mozilla.com at Fri, 04 Dec 2015 23:28:54 +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 292306
Push 962 by jlund@mozilla.com at Fri, 04 Dec 2015 23:28:54 +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 292305
Push 962 by jlund@mozilla.com at Fri, 04 Dec 2015 23:28:54 +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 292304
Push 962 by jlund@mozilla.com at Fri, 04 Dec 2015 23:28:54 +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 292303
Push 962 by jlund@mozilla.com at Fri, 04 Dec 2015 23:28:54 +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 292302
Push 962 by jlund@mozilla.com at Fri, 04 Dec 2015 23:28:54 +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 292301
Push 962 by jlund@mozilla.com at Fri, 04 Dec 2015 23:28:54 +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 292300
Push 962 by jlund@mozilla.com at Fri, 04 Dec 2015 23:28:54 +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 292299
Push 962 by jlund@mozilla.com at Fri, 04 Dec 2015 23:28:54 +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.
d05f091bf4d8d28c789e27a122bc9bfc096e8d63: Bug 1190970: [MSE] P1. Enable WebM by default on platforms not supporting h264/aac. r=cpeterson
Jean-Yves Avenard <jyavenard@mozilla.com> - Tue, 11 Aug 2015 08:55:39 +1000 - rev 292298
Push 962 by jlund@mozilla.com at Fri, 04 Dec 2015 23:28:54 +0000
Bug 1190970: [MSE] P1. Enable WebM by default on platforms not supporting h264/aac. r=cpeterson
c95b78847e3c140a094f019b5c58f0830cec2c65: bug 1191889 skip Close() when not initialized r=roc
Karl Tomlinson <karlt+@karlt.net> - Mon, 17 Aug 2015 10:07:50 +1200 - rev 292297
Push 962 by jlund@mozilla.com at Fri, 04 Dec 2015 23:28:54 +0000
bug 1191889 skip Close() when not initialized r=roc
c790c2fe70dafd681810f7b592113a029c290220: bug 962719 remove unnecessary OneIteration() parameters aFrom/aTo r=padenot
Karl Tomlinson <karlt+@karlt.net> - Tue, 04 Aug 2015 19:42:10 +1200 - rev 292296
Push 962 by jlund@mozilla.com at Fri, 04 Dec 2015 23:28:54 +0000
bug 962719 remove unnecessary OneIteration() parameters aFrom/aTo r=padenot
d0b0a8015ca0c5fb5df88c14bcd8101d48b1a080: bug 962719 remove notified blocked warning of finished stream r=padenot
Karl Tomlinson <karlt+@karlt.net> - Fri, 31 Jul 2015 22:49:55 +1200 - rev 292295
Push 962 by jlund@mozilla.com at Fri, 04 Dec 2015 23:28:54 +0000
bug 962719 remove notified blocked warning of finished stream r=padenot Finished can be determined immediately after mFinished is set, but blocked is not determined until RecomputeBlocking() has run.
(0) -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 tip