5b6b7472ff5a853c7e9678741e83773f2bb5693b: Bug 1182961 (part 5, attempt 2) - Use nsTHashtable::Iterator in nsCookieService. r=michal.
Nicholas Nethercote <nnethercote@mozilla.com> - Sun, 26 Jul 2015 23:40:51 -0700 - rev 288412
Push 5067 by raliiev@mozilla.com at Mon, 21 Sep 2015 14:04:52 +0000
Bug 1182961 (part 5, attempt 2) - Use nsTHashtable::Iterator in nsCookieService. r=michal.
322a318dafa84098a984c1f3eecba8fcdb299897: Bug 1182961 (part 4, attempt 2) - Use nsTHashtable::Iterator in CacheFileHandles. r=michal.
Nicholas Nethercote <nnethercote@mozilla.com> - Sun, 26 Jul 2015 23:31:22 -0700 - rev 288411
Push 5067 by raliiev@mozilla.com at Mon, 21 Sep 2015 14:04:52 +0000
Bug 1182961 (part 4, attempt 2) - Use nsTHashtable::Iterator in CacheFileHandles. r=michal.
e3431a4745626d5c7e6cbe2054f10500fe2232f1: Bug 1188322 - Always hide menubar as well as dock for fullscreen on OS X whatever the screen is. r=mstange
Xidorn Quan <quanxunzhen@gmail.com> - Fri, 07 Aug 2015 13:49:12 +1000 - rev 288410
Push 5067 by raliiev@mozilla.com at Mon, 21 Sep 2015 14:04:52 +0000
Bug 1188322 - Always hide menubar as well as dock for fullscreen on OS X whatever the screen is. r=mstange
7409dc9f90d71b6a6e5f4e4820f99be843a481a2: Bug 1192063 - Create a stacking context for the tab overlay icon so that its background paints in front of the tab image; r=jaws
Ehsan Akhgari <ehsan@mozilla.com> - Thu, 06 Aug 2015 20:16:06 -0400 - rev 288409
Push 5067 by raliiev@mozilla.com at Mon, 21 Sep 2015 14:04:52 +0000
Bug 1192063 - Create a stacking context for the tab overlay icon so that its background paints in front of the tab image; r=jaws
dc3a755872e1ff6ecbc0465876b6d554921217c2: Bug 1192109 - Fix insufficient includes in MediaEventSource.h. r=kinetik.
JW Wang <jwwang@mozilla.com> - Fri, 07 Aug 2015 11:11:18 +0800 - rev 288408
Push 5067 by raliiev@mozilla.com at Mon, 21 Sep 2015 14:04:52 +0000
Bug 1192109 - Fix insufficient includes in MediaEventSource.h. r=kinetik.
dee3e26cc1c0f4deeb49eaa06b03a3c06ac4927f: Bug 1186890 - Ensure parent always know when the child exit fullscreen. r=Dolske
Xidorn Quan <quanxunzhen@gmail.com> - Fri, 07 Aug 2015 13:38:10 +1000 - rev 288407
Push 5067 by raliiev@mozilla.com at Mon, 21 Sep 2015 14:04:52 +0000
Bug 1186890 - Ensure parent always know when the child exit fullscreen. r=Dolske
9060b380602b0580be686f64176dfcf4732d71cf: Bug 1181392 part 10 - Remove KeyframeEffect::IsFinishedTransition; r=dbaron
Brian Birtles <birtles@gmail.com> - Fri, 07 Aug 2015 12:29:36 +0900 - rev 288406
Push 5067 by raliiev@mozilla.com at Mon, 21 Sep 2015 14:04:52 +0000
Bug 1181392 part 10 - Remove KeyframeEffect::IsFinishedTransition; r=dbaron
76626b00fac91ccc669e704da276498e61695178: Bug 1181392 part 9 - Remove use of IsFinishedTransition from nsTransitionManager::FlushTransitions; r=dbaron
Brian Birtles <birtles@gmail.com> - Fri, 07 Aug 2015 12:29:36 +0900 - rev 288405
Push 5067 by raliiev@mozilla.com at Mon, 21 Sep 2015 14:04:52 +0000
Bug 1181392 part 9 - Remove use of IsFinishedTransition from nsTransitionManager::FlushTransitions; r=dbaron This patch updates the logic in nsTransitionManager::FlushTransitions that deals with detecting newly-started (i.e. when the delay phase has just finished) or newly-finished animations. The existing logic had the following behavior: * Calling SetIsFinishedTransition for newly-finished transitions. This is no longer needed since by this point all consumers of IsFinishedTransition have been updated to use alternative means for testing if an animation is relevant. * Setting transitionStartedOrEnded to true so that we would post an animation restyle. We can achieve this same effect by simplying updating the canThrottleTick flag using the result of calling Animation::CanThrottle on each animation. Animation::CanThrottle will return false for a newly-started or newly-finished animation (it returns false for a newly-started animation since the animation's mIsRunningOnCompositor flag won't yet be true at that point.) * Updating the animation generation for newly-started and newly-finished animations in order to trigger a layer update. At least that appears to be the intention of this code. However, it currently has no effect since the animation generation on the pres context is not incremented in any context I could find where a newly started/finished animation might be detected. For this third case, this patch adds tests to ensure that transitions are correctly added and removed from the compositor when they start and finish. This is because most of the existing tests in test_animations_omta.html cover only CSS animations. As noted in the comments in the test, if a tick lands at the exact beginning of a transition we will typically not send it to the layer until the following tick because the RestyleManager will filter out the seemingly redundant change (i.e. no change to the computed style). Presumably updating the animation generation was intended to avoid this. This same behavior is true of CSS animations (and the same kind of comment appears elsewhere in test_animations_omta.html). Long-term this is probably worth fixing so that when a transition is triggered we get it to the compositor one tick earlier which should improve responsiveness when the main thread is busy and the interval between ticks is long. Furthermore, we should do the same for both all type of animations, not just transitions. Currently, however, this patch preserves the existing behavior and helps narrow the difference between transitions and animations so we can apply this optimization to both.
c105cadd52e2ba00b5b87718a59c7da7eeb459df: Bug 1181392 part 8 - Remove use of IsFinishedTransition from nsTransitionManager::PruneCompletedTransitions; r=dbaron
Brian Birtles <birtles@gmail.com> - Fri, 07 Aug 2015 12:29:36 +0900 - rev 288404
Push 5067 by raliiev@mozilla.com at Mon, 21 Sep 2015 14:04:52 +0000
Bug 1181392 part 8 - Remove use of IsFinishedTransition from nsTransitionManager::PruneCompletedTransitions; r=dbaron This patch generalizes the logic in nsTransitionManager::PruneCompletedTransitions to consider all transitions that are no longer current (i.e. not running or scheduled to run) rather than those marked as finished.
766cbaaa78792f400079900ab1b31b02adcd6026: Bug 1181392 part 7 - Remove use of IsFinishedTransition from nsTransitionManager::ConsiderStartingTransition; r=dbaron
Brian Birtles <birtles@gmail.com> - Fri, 07 Aug 2015 12:29:36 +0900 - rev 288403
Push 5067 by raliiev@mozilla.com at Mon, 21 Sep 2015 14:04:52 +0000
Bug 1181392 part 7 - Remove use of IsFinishedTransition from nsTransitionManager::ConsiderStartingTransition; r=dbaron Of particular note, this patch removes the check for finished transitions in the case when we can't animate the current change. This case occurs when either we have a non-transition style change that happens to coincide with the current transition value, or a style change to something we can't interpolate to. In either case it's not clear why we would cancel the existing transition only if it is still in motion and not if it is finished. It seems like it should be cancelled in either case and hence this patch removes this check. The other change relates to detecting reversing transitions. In this case we do need to distinguish between transitions that have finished and those that have not. For this purpose, checking if the animation is current should be sufficient. (Note that comparing for PlayState() == Finished would not be enough since we want to also exclude *idle*, i.e. cancelled, animations too.)
5448e9a763c47f2460ffa414ebd3e856c7e3a549: Bug 1181392 part 6 - Remove use of IsFinishedTransition from nsTransitionManager::StyleContextChanged; r=dbaron
Brian Birtles <birtles@gmail.com> - Fri, 07 Aug 2015 12:29:36 +0900 - rev 288402
Push 5067 by raliiev@mozilla.com at Mon, 21 Sep 2015 14:04:52 +0000
Bug 1181392 part 6 - Remove use of IsFinishedTransition from nsTransitionManager::StyleContextChanged; r=dbaron In StyleContextChanged, when we drop a transition, we also update the animation generation, unless the transition is finished. This is so that we will update animations on layers accordingly. For all intents and purposes this is equivalent to only updating the animation generation if the animation is current. Even in the case where the transition has *just* finished, it will either already be considered finished and the regular animation tick (which uses the same refresh driver time as we see in StyleContextChanged) will have triggered an unthrottled sample to take the animation off the compositor (since Animation::CanThrottle detects newly finished animations), or it will be not yet finished in which case HasCurrentEffect will return true. If anything changed timing properties in the time between running the refresh driver tick and calling StyleContextChanged (such as seeking the Animation) it will also trigger a layer update. This patch also removes an unncessary assertion in ElementPropertyTransition::CurrentValuePortion. This functions operates sensibly even for finished transitions (due to the way it manages the fill mode). It is up to the call site to determine whether it should be calling this function on a finished transition or not.
c9b2670f5c1a1fed0cef6b7fa2b98b1f3fa789be: Bug 1181392 part 5 - Remove use of IsFinishedTransition from AnimationCollection::HasAnimationOfProperty; r=dbaron
Brian Birtles <birtles@gmail.com> - Fri, 07 Aug 2015 12:29:36 +0900 - rev 288401
Push 5067 by raliiev@mozilla.com at Mon, 21 Sep 2015 14:04:52 +0000
Bug 1181392 part 5 - Remove use of IsFinishedTransition from AnimationCollection::HasAnimationOfProperty; r=dbaron AnimationCollection::HasAnimationOfProperty uses IsFinishedTransition to filter out transitions that should otherwise be ignored. This is used in the following places: 1. nsLayoutUtils::HasAnimations The is only used by nsIFrame::BuildDisplayListForStackingContext to see if there are any opacity animations For this case, simply returning *current* animations would be sufficient (since finished but filling animations should have already filled in the display opacity) 2. CommonAnimationManager::GetAnimationsForCompositor This should really only return *current* animations--that is, animations that are running or scheduled to run. Finished animations never run on the compositor. Indeed, only *playing* animations run on the compositor but, as we will see in some of the cases below, it is sometimes useful to know that an animation *will* run on the compositor in the near future (e.g. so we can pre-render content). The places where GetAnimationsForCompositor is used are: - When building layers to add animations to layers in nsDisplayList--in this case we skip any animations that aren't playing so if GetAnimationsForCompositor only returned current animations that would be more than sufficient. - In nsLayoutUtils::HasAnimationsForCompositor. This in turn is used: - In ChooseScaleAndSetTransform to see if the transform is being animated on the compositor. If so, it calls nsLayoutUtils::ComputeSuitableScaleForAnimation (which also calls GetAnimationsForCompositor) and passes the result to GetMinAndMaxScaleForAnimationProperty which we have already adjusted in part 4 of this patch series to only deal with *relevant* animations Relevant animations include both current animations and in effect animations but we don't run forwards-filling animations on the compositor so GetAnimationsForCompositor should NOT return them. Current animations should be enough. In fact, playing animations should be enough but we might want to pre-render layers at a suitable size during their delay phase so returning current animations is probably ok. - In nsDisplayListBuilder::MarkOutOfFlowFrameForDisplay to add a fuzz factor to the overflow rect for frames undergoing a transform animation on the compositor. In this case too current animations should be sufficient. - In nsDisplayOpacity::NeedsActiveLayer to say "yes" if we are animating opacity on the compositor. Presumably in this case it would be good to say "yes" if the animation is in the delay phase too (as it currently does). After the animation is finished, we should drop the layer, i.e. current animations should be sufficient. - In nsDisplayTransform::ShouldPrerenderTransformedContent. As with nsDisplayOpacity::NeedsActiveLayer, we only need to pre-render transformed content for animations that are current. - In nsDisplayTransform::GetLayerState. As with nsDisplayOpacity::NeedsActiveLayer, we only need to return active here for current animations. - In nsIFrame::IsTransformed. Here we test the display style to see if there is a transform and also check if transform is being animated on the compositor. As a result, we really only need HasAnimationsForCompositor to return true for animations that are playing--otherwise the display style will tell us if we're transformed or not. Returning true for all current compositor animations (which is a superset of playing), however, should not cause problems (we already return true for even more than that). - In nsIFrame::HasOpacityInternal which is much the same as nsIFrame::IsTransformed and hence current should be fine. 3. AnimationCollection::CanThrottleAnimation Here, HasAnimationOfProperty is used when looking for animations that would disqualify us from throttling the animation by having an out-of-date layer generation or being a transform animation that affects scroll and so requires that we do the occasional main thread sample to update scrollbars. It would seem like current animations are enough here too. One interesting case is where we *had* a compositor animation but it has finished or been cancelled. In that case, the animation won't be current and we should not throttle the animation since we need to take it off its layer. It turns out checking for current animations is still ok in this case too. The reasoning is as follows: - If the animation is newly-finished, we'll pick that up in Animation::CanThrottle and return false then. - If the animation is newly-idle then there are two cases: If the cancelled animation was the only compositor animation then AnimationCollection::CanPerformOnCompositorThread will notice that there are no playing compositor animations and return false and AnimationCollection::CanThrottleAnimation will never be called. If there are other compositor animations running, then AnimationCollection::CanThrottleAnimation will still return false because whatever cancelled the animation will update the animation generation and we'll notice the mismatch between the layer animation generation and the animation generation on the collection. Based on the above analysis it appears that making AnimationCollection::HasAnimationOfProperty return only current animations (and simulatneously renaming it to HasCurrentAnimationOfProperty) is safe. Indeed, in effect, we already do this for transitions but not for animations. This patch generalizes this behavior to all animations. This patch also updates test_animations_omta.html since it was incorrectly testing that a finished opacity animation was still running on the compositor. Finished animations should not run on the compositor and the changes in this patch cause that to happen. The reason we don't just update this test to check for RunningOn.MainThread is that for opacity animations, unlike transform animations, we can't detect if an opacity on a layer was set by animation or not. As a result, for opacity animations we typically test the opacity on either the main thread or compositor in order to allow for the case where an animation-set opacity is still lingering on the compositor.
f8b8e1084b4080b39a8278112aa4519cd0db0eba: Bug 1181392 part 4 - Remove use of IsFinishedTransition from nsLayoutUtils; r=dbaron
Brian Birtles <birtles@gmail.com> - Fri, 07 Aug 2015 12:29:36 +0900 - rev 288400
Push 5067 by raliiev@mozilla.com at Mon, 21 Sep 2015 14:04:52 +0000
Bug 1181392 part 4 - Remove use of IsFinishedTransition from nsLayoutUtils; r=dbaron GetMinAndMaxScaleForAnimationProperty in nsLayoutUtils uses IsFinishedTransition to ignore finished transitions since they should not have any effect on current or future scale values. We can generalize this, however, and say we are only interested in animations that are *either*: a) running or scheduled to run in the future, i.e. "current", OR b) applying a value, including a finished animation with a forwards fill, i.e. "in effect" Elsewhere, animations that fulfil *either* of this conditions are referred to as "relevant animations" so we can simply test for relevance in this function.
bcf2c0c393cf0642f7a100c3e4e7d6b0b6b748f5: Bug 1181392 part 3 - Remove use of IsFinishedTransition in KeyframeEffectReadOnly; r=dbaron
Brian Birtles <birtles@gmail.com> - Fri, 07 Aug 2015 12:29:35 +0900 - rev 288399
Push 5067 by raliiev@mozilla.com at Mon, 21 Sep 2015 14:04:52 +0000
Bug 1181392 part 3 - Remove use of IsFinishedTransition in KeyframeEffectReadOnly; r=dbaron KeyframeEffectReadOnly uses IsFinishedTransition to exclude finished transitions from certain tests. This check, however, is redundant in each case. This is because any effect marked as IsFinishedTransition will have the following properties: - owning animation's PlayState() == Finished or Idle - animation phase = after or null - progress = null (this is because transitions don't fill forwards)
4e8a8884e36ff65a91e732c0f5ed17dc823e565b: Bug 1181392 part 2 - Remove use of IsFinishedTransition from Animation::ComposeStyle; r=dbaron
Brian Birtles <birtles@gmail.com> - Fri, 07 Aug 2015 12:29:35 +0900 - rev 288398
Push 5067 by raliiev@mozilla.com at Mon, 21 Sep 2015 14:04:52 +0000
Bug 1181392 part 2 - Remove use of IsFinishedTransition from Animation::ComposeStyle; r=dbaron Animation::ComposeStyle uses IsFinishedTransition to skip doing work for transitions that have run their course. We can, however, generalize this to cover all animations that are not currently contributing to the animated style--that is animations that are not "in effect". We need to add this check *after* we update aNeedsRefreshes since an animation that is not "in effect" because it has a delay and no backwards fill (in this case it will have a play state of "running") still needs refreshes.
7fa8a6d1f67f9e3ab960de0b539100169e926727: Bug 1181392 part 1 - Remove use of IsFinishedTransition from Animation::CanThrottle; r=dbaron
Brian Birtles <birtles@gmail.com> - Fri, 07 Aug 2015 12:29:35 +0900 - rev 288397
Push 5067 by raliiev@mozilla.com at Mon, 21 Sep 2015 14:04:52 +0000
Bug 1181392 part 1 - Remove use of IsFinishedTransition from Animation::CanThrottle; r=dbaron Previously we used IsFinishedTransition so that if the only animations present are finished transitions we could throttle the tick. In fact, this probably shouldn't even be necessary since we shouldn't be calling CanThrottle if AnimationCollection::mNeedsRefreshes is false. However, so long as we're performing this test it turns out we can generalize this further and throttle ticks for all finished animations that are not newly finished, regardless of whether they are running on the compositor or not (although this method won't be called unless the animation property could be run on the compositor anyway). This method is somewhat confusing. For one, it is not strictly limited to animations that are running on the compositor. It appears to only return true when the animation is running on the compositor but the mIsRunningOnCompositor flag doesn't get cleared when the animation finishes (bug 1151694). As a result this method also deals with animations that are now running on the main thread. This patch makes us deal with such animations more consistently. This patch also reworks this method so that it's hopefully a little easier to follow and a little more consistent since I spent several hours trying to understand the different combinations of inputs this method could take and what question it was trying to answer.
e14cb4eb7c0bdd00b20ab6ff212e5f72158b12a9: Bug 1190735 - Remove nsITimer.TYPE_REPEATING_PRECISE. r=froydnj.
Nicholas Nethercote <nnethercote@mozilla.com> - Tue, 04 Aug 2015 17:30:53 -0700 - rev 288396
Push 5067 by raliiev@mozilla.com at Mon, 21 Sep 2015 14:04:52 +0000
Bug 1190735 - Remove nsITimer.TYPE_REPEATING_PRECISE. r=froydnj.
f58ce99d0d99256512a5e5f7f648a98b9d4b5da7: Bug 1191959 - Make sure that pinned tabs are still clickable after unuting a tab that is not playing; r=jaws
Ehsan Akhgari <ehsan@mozilla.com> - Thu, 06 Aug 2015 22:29:06 -0400 - rev 288395
Push 5067 by raliiev@mozilla.com at Mon, 21 Sep 2015 14:04:52 +0000
Bug 1191959 - Make sure that pinned tabs are still clickable after unuting a tab that is not playing; r=jaws This bug happens becuase when toggleMuteAudio() is called from the click handler for the tab, we remove the muted attribute during unmuting, which makes the element display:none. Therefore, when the mouse pointer leaves that region, there is no element to receive the mouseout event and as a result, the _overPlayingIcon variable stays true, which means we stop tab switching in the mousedown handler.
6fb2fb69fe674e2b776a427f4f3e36f235aa3a55: Bug 1191173 - Mirror MediaDecoder::mSameOriginMedia in MDSM. r=jya.
JW Wang <jwwang@mozilla.com> - Thu, 06 Aug 2015 18:05:30 +0800 - rev 288394
Push 5067 by raliiev@mozilla.com at Mon, 21 Sep 2015 14:04:52 +0000
Bug 1191173 - Mirror MediaDecoder::mSameOriginMedia in MDSM. r=jya.
feb18f1bdeaac7c8e3122824c307b3314747d1ee: Bug 1188131: Don't rely on MediaResource type to detect media format. r=cpearce
Jean-Yves Avenard <jyavenard@mozilla.com> - Thu, 06 Aug 2015 21:06:45 +1000 - rev 288393
Push 5067 by raliiev@mozilla.com at Mon, 21 Sep 2015 14:04:52 +0000
Bug 1188131: Don't rely on MediaResource type to detect media format. r=cpearce This information is often wrong and non-existent with MSE. Let the PDM decides later based on the metadata. This prevent hardware acceleration to be turned on leading to extremely high CPU usage on high definition videos.
(0) -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 tip