90d854c1fb68cf9bdf5b07f1c1c8940d3315d93d: Bug 1190988 - Hit testing appears to return incorrect positions when --enable-android-apz is specified. r=kats
Randall Barker <rbarker@mozilla.com> - Thu, 06 Aug 2015 12:59:00 +0200 - rev 288418
Push 5067 by raliiev@mozilla.com at Mon, 21 Sep 2015 14:04:52 +0000
Bug 1190988 - Hit testing appears to return incorrect positions when --enable-android-apz is specified. r=kats The BrowserEventHandler was still being initialized when the C++ APZ is being utilized which was causing event positions to be incorrectly converted in certain cases.
6e166fef1a0f7406b73804c9a04c136086dc257e: Backed out changeset 9618f92995ab (bug 1166323) for linux x64 test bustage on a CLOSED TREE
Carsten "Tomcat" Book <cbook@mozilla.com> - Fri, 07 Aug 2015 07:24:40 +0200 - rev 288417
Push 5067 by raliiev@mozilla.com at Mon, 21 Sep 2015 14:04:52 +0000
Backed out changeset 9618f92995ab (bug 1166323) for linux x64 test bustage on a CLOSED TREE
7bfb63119f1ce5fc543c02882e3d4dcfc316196c: Bug 1188812 - Obtain CDM can render capability and store into MediaInfo r=cpearce.
Kilik Kuo <kikuo@mozilla.com> - Thu, 06 Aug 2015 14:24:00 +0800 - rev 288416
Push 5067 by raliiev@mozilla.com at Mon, 21 Sep 2015 14:04:52 +0000
Bug 1188812 - Obtain CDM can render capability and store into MediaInfo r=cpearce.
79ecbf9133b17d4e1219da2f5222192e9c2bc084: Bug 1051604 - Adapt VAD strategy on SpeechRecognition to be less strict on some devices with poor mics. r=smaug
Andre Natal <anatal@gmail.com> - Wed, 05 Aug 2015 20:47:00 +0200 - rev 288415
Push 5067 by raliiev@mozilla.com at Mon, 21 Sep 2015 14:04:52 +0000
Bug 1051604 - Adapt VAD strategy on SpeechRecognition to be less strict on some devices with poor mics. r=smaug
9618f92995ab60eb6dc0546a93d4fef0e44cf27a: Bug 1166323 - Fix unexpcetd changed on previous landed. r=dkeeler
Makoto Kato <m_kato@ga2.so-net.ne.jp> - Fri, 07 Aug 2015 13:41:49 +0900 - rev 288414
Push 5067 by raliiev@mozilla.com at Mon, 21 Sep 2015 14:04:52 +0000
Bug 1166323 - Fix unexpcetd changed on previous landed. r=dkeeler
e8e3aef9b935721c1b527aea0dfa8c531806af73: Backout unrelated code landed in dee3e26cc1c0 by mistake.
Xidorn Quan <quanxunzhen@gmail.com> - Fri, 07 Aug 2015 14:40:16 +1000 - rev 288413
Push 5067 by raliiev@mozilla.com at Mon, 21 Sep 2015 14:04:52 +0000
Backout unrelated code landed in dee3e26cc1c0 by mistake.
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)
(0) -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 tip