52390d9090fbd8d46b00ea29034e7039511ff8a4: Bug 1530774 - Part 3. Remove decoder support for producing paletted frames. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Fri, 15 Mar 2019 13:29:02 -0400 - rev 506561
Push 138 by mtabara@mozilla.com at Wed, 20 Mar 2019 18:12:49 +0000
Bug 1530774 - Part 3. Remove decoder support for producing paletted frames. r=tnikkel Differential Revision: https://phabricator.services.mozilla.com/D23716
6dd55ee8961128d0c9e314d60e7509604e7548b2: Bug 1530774 - Part 2. Remove support for paletted surface pipes. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Mon, 11 Mar 2019 14:05:59 -0400 - rev 506560
Push 138 by mtabara@mozilla.com at Wed, 20 Mar 2019 18:12:49 +0000
Bug 1530774 - Part 2. Remove support for paletted surface pipes. r=tnikkel Differential Revision: https://phabricator.services.mozilla.com/D23715
e3315d7842089083b389fc666b51c693c05924fc: Bug 1530774 - Part 1. Remove support in FrameAnimator for blending partial/paletted frames. r=tnikkel
Andrew Osmond <aosmond@mozilla.com> - Mon, 11 Mar 2019 13:20:49 -0400 - rev 506559
Push 138 by mtabara@mozilla.com at Wed, 20 Mar 2019 18:12:49 +0000
Bug 1530774 - Part 1. Remove support in FrameAnimator for blending partial/paletted frames. r=tnikkel Differential Revision: https://phabricator.services.mozilla.com/D23714
551c4286614374560dbff3ac3fc2a0f9de9b971e: Bug 1535016 - Don't treat any Android job as new job r=jmaher
Ionut Goldan <igoldan@mozilla.com> - Mon, 18 Mar 2019 10:32:12 +0000 - rev 506558
Push 138 by mtabara@mozilla.com at Wed, 20 Mar 2019 18:12:49 +0000
Bug 1535016 - Don't treat any Android job as new job r=jmaher Differential Revision: https://phabricator.services.mozilla.com/D23674
93b549966e0af3cd63270e0d851feaa1199154c8: Bug 1518816 - Set the NS_FRAME_MAY_BE_TRANSFORMED bit for animations when we check for the EffectSet; r=hiro
Brian Birtles <birtles@gmail.com> - Mon, 18 Mar 2019 04:12:38 +0000 - rev 506557
Push 138 by mtabara@mozilla.com at Wed, 20 Mar 2019 18:12:49 +0000
Bug 1518816 - Set the NS_FRAME_MAY_BE_TRANSFORMED bit for animations when we check for the EffectSet; r=hiro Currently the way we set the NS_FRAME_MAY_BE_TRANSFORMED frame bit for transform animations fails to take into account the primary/style frame distinction for display:table content. This patch moves setting that bit for animations to the point where we already have a handle on the appropriate EffectSet and already detect the primary/style frame distinction. This should be equivalent because: a) Although it is inside a branch that is only run when |mContent| is set, nsLayoutUtils::HasAnimationOfPropertySet will return false if the passed-in frame does not have associated content (see EffectCompositor::GetAnimationElementAndPseudoForFrame). b) EffectSet::MayHaveTransformAnimation() should be set if we have any transform animations in the EffectSet so this should be equivalent to querying nsLayoutUtils::HasAnimationOfPropertySet. The only other consideration is that this code is only executed when aPrevInFlow is nullptr. As a result, this patch also updates the branch where aPrevInFlow is set to copy the NS_FRAME_MAY_BE_TRANSFORMED bit in that case too. Differential Revision: https://phabricator.services.mozilla.com/D23636
e7c2055118e59b47284ce16b1233f7697e982efb: Bug 1518816 - Set the "may have transform animations" flag on the primary frame; r=hiro
Brian Birtles <birtles@gmail.com> - Mon, 18 Mar 2019 04:12:23 +0000 - rev 506556
Push 138 by mtabara@mozilla.com at Wed, 20 Mar 2019 18:12:49 +0000
Bug 1518816 - Set the "may have transform animations" flag on the primary frame; r=hiro Differential Revision: https://phabricator.services.mozilla.com/D23635
39e15f2bd75cc6acc3bd5c5030c404c261cb5809: Bug 1518816 - Add a crashtest for a scale animation on a block continuation; r=hiro
Brian Birtles <birtles@gmail.com> - Mon, 18 Mar 2019 04:12:16 +0000 - rev 506555
Push 138 by mtabara@mozilla.com at Wed, 20 Mar 2019 18:12:49 +0000
Bug 1518816 - Add a crashtest for a scale animation on a block continuation; r=hiro Differential Revision: https://phabricator.services.mozilla.com/D23614
3dbf8012e5a462521f89a75fdbfde6d272584edb: Bug 1518816 - Rename EffectSet::GetEffectSet(const nsIFrame*) to make it more clear what it does; r=hiro
Brian Birtles <birtles@gmail.com> - Mon, 18 Mar 2019 04:12:14 +0000 - rev 506554
Push 138 by mtabara@mozilla.com at Wed, 20 Mar 2019 18:12:49 +0000
Bug 1518816 - Rename EffectSet::GetEffectSet(const nsIFrame*) to make it more clear what it does; r=hiro Differential Revision: https://phabricator.services.mozilla.com/D23286
aa46ab77475694e771a6988154b263bb56502b47: Bug 1518816 - Make nsLayoutUtils utility functions for getting animations use the EffectSet::GetEffectSetForFrame; r=hiro
Brian Birtles <birtles@gmail.com> - Mon, 18 Mar 2019 04:12:12 +0000 - rev 506553
Push 138 by mtabara@mozilla.com at Wed, 20 Mar 2019 18:12:49 +0000
Bug 1518816 - Make nsLayoutUtils utility functions for getting animations use the EffectSet::GetEffectSetForFrame; r=hiro Differential Revision: https://phabricator.services.mozilla.com/D23285
e5bf7eaa0189769d3bbafaf04ded15e627bff9ce: Bug 1518816 - Rework AnimationUtils::EffectSetContainsAnimatedScale to handle looking up the effect set correctly; r=hiro
Brian Birtles <birtles@gmail.com> - Mon, 18 Mar 2019 04:12:10 +0000 - rev 506552
Push 138 by mtabara@mozilla.com at Wed, 20 Mar 2019 18:12:49 +0000
Bug 1518816 - Rework AnimationUtils::EffectSetContainsAnimatedScale to handle looking up the effect set correctly; r=hiro Differential Revision: https://phabricator.services.mozilla.com/D23284
a87a6c5b555072e97cb884326907eb70bd5b7b39: Bug 1518816 - Use the primary frame in KeyframeEffect::CanAnimateTransformOnCompositor; r=hiro
Brian Birtles <birtles@gmail.com> - Mon, 18 Mar 2019 04:10:49 +0000 - rev 506551
Push 138 by mtabara@mozilla.com at Wed, 20 Mar 2019 18:12:49 +0000
Bug 1518816 - Use the primary frame in KeyframeEffect::CanAnimateTransformOnCompositor; r=hiro For most of the functions we call on this frame there will be no difference in result since the transform styles are inherited from the style frame to the primary frame. However, for Combines3DTransformWithAncestors() at least, which calls IsCSSTransformed(), the result will differ. Differential Revision: https://phabricator.services.mozilla.com/D23283
296f63c52362834aef096a7e91c68781f9a19325: Bug 1518816 - Add EffectSet::GetEffectSetForFrame and use it in FindAnimationsForCompositor; r=hiro
Brian Birtles <birtles@gmail.com> - Mon, 18 Mar 2019 04:10:30 +0000 - rev 506550
Push 138 by mtabara@mozilla.com at Wed, 20 Mar 2019 18:12:49 +0000
Bug 1518816 - Add EffectSet::GetEffectSetForFrame and use it in FindAnimationsForCompositor; r=hiro There are many bugs regarding our use of EffectSet::GetEffectSet(nsIFrame*) because the intention of the caller is not clear. If it is called for the primary frame of display:table content do we expect it to get the EffectSet associated with the style frame or not? Generally it depends on if we are looking for transform animations or not. Rather than inspecting each call site and making it choose the appropriate frame to use, this patch introduces a new method to EffectSet to get the appropriate EffectSet based on the properties the caller is interested in. This patch also uses this function in FindAnimationsForCompositor which in turns fixes the glitching observed on Tumblr that arose since a number of places in our display list code were passing the style frame to EffectCompositor::HasAnimationsForCompositor. Over the remainder of this patch series we will convert more callers of EffectSet::GetEffectSet(nsIFrame*) to this new method before renaming EffectSet::GetEffectSet to GetEffectSetForStyleFrame to make clear how the method is intended to work. Differential Revision: https://phabricator.services.mozilla.com/D23282
8d9300956e10179cac87aff5f1a14d44776b2bf3: Bug 1518816 - Clarify when and why KeyframeEffect::HasEffectiveAnimationOfPropertySet might return false even when there are effective animations in a property set; r=boris
Brian Birtles <birtles@gmail.com> - Mon, 18 Mar 2019 04:10:10 +0000 - rev 506549
Push 138 by mtabara@mozilla.com at Wed, 20 Mar 2019 18:12:49 +0000
Bug 1518816 - Clarify when and why KeyframeEffect::HasEffectiveAnimationOfPropertySet might return false even when there are effective animations in a property set; r=boris It took me a long time to understand why KeyframeEffect::HasEffectiveAnimationOfPropertySet behaved so differently to KeyframeEffect::HasAnimationOfPropertySet. This patch attempts to clarify that while making KeyframeEffect::HasEffectiveAnimationOnPropertySet a little more generally useful. This will allow us to tidy up the various animation checks in nsLayoutUtils later in this patch series. Ultimately, however, we should make this check part of the regular compositor animation vetting machinery in bug 1534884. That should remove a number of inconsistencies such that we don't need the extended comments added in this patch. Differential Revision: https://phabricator.services.mozilla.com/D23281
b6614bc4be3f279d70fbd9a85f5a84b8445699ab: Bug 1518816 - Replace nsLayoutUtils::HasCurrentTransition with something that takes an element/pseudo pair; r=hiro
Brian Birtles <birtles@gmail.com> - Mon, 18 Mar 2019 04:09:55 +0000 - rev 506548
Push 138 by mtabara@mozilla.com at Wed, 20 Mar 2019 18:12:49 +0000
Bug 1518816 - Replace nsLayoutUtils::HasCurrentTransition with something that takes an element/pseudo pair; r=hiro The trouble with utility functions that take an nsIFrame is it's not clear what the caller's intention is. For example, with nsLayoutUtils::HasCurrentTransition, is the caller asking for transitions on that frame? Or animations on _both_ that frame and its corresponding style/primary frame? Probably the caller hasn't even thought about it and there are likely to be bugs when display:table content is encountered. Where practical it's much better to take an element/pseudo pair since it's clear that the caller is concerned with all animations (or transitions in this case) on the element regardless of how it is represented in the frame tree. This patch updates nsLayoutUtils::HasCurrentTransition to take an element/pseudo pair and moves it to mozilla::AnimationUtils at the same time. Differential Revision: https://phabricator.services.mozilla.com/D23280
925ae534d52120a5d3a6be483a1271272d52c9b8: Bug 1518816 - Look up the will-change style on the _style_ frame for will-change: transform; r=mattwoodrow
Brian Birtles <birtles@gmail.com> - Mon, 18 Mar 2019 04:09:35 +0000 - rev 506547
Push 138 by mtabara@mozilla.com at Wed, 20 Mar 2019 18:12:49 +0000
Bug 1518816 - Look up the will-change style on the _style_ frame for will-change: transform; r=mattwoodrow I was unable to create a failing reftest for this since this method is not used when determining whether or not to create a stacking context. However, I verified that for content with animated transforms and will-change:transform on display:table content this change does cause us to return true from the will-change check in this method when previously it would not. Differential Revision: https://phabricator.services.mozilla.com/D23279
dd7400edcf025f74b42eb6864704d2f35c192ba3: Bug 1518816 - Make sure all transform-related properties are inherited from a table's inner frame to its wrapper frame; r=mattwoodrow
Brian Birtles <birtles@gmail.com> - Mon, 18 Mar 2019 04:09:21 +0000 - rev 506546
Push 138 by mtabara@mozilla.com at Wed, 20 Mar 2019 18:12:49 +0000
Bug 1518816 - Make sure all transform-related properties are inherited from a table's inner frame to its wrapper frame; r=mattwoodrow We test the transform-style of a frame in places like KeyframeEffect::CanAnimateTransformOnCompositor but this will likely not work as expected for display:table content since the transform-style will not be inherited to the primary frame (and later in this patch series we will ensure that we are dealing with the primary frame in KeyframeEffect::CanAnimateTransformOnCompositor). The individual transform properties are new but they should also be inherited so that all the appropriate tests for "is this frame transformed?" produce the correct result when these properties are applied. Differential Revision: https://phabricator.services.mozilla.com/D23278
1bab6b17eee5ace1773d3b910733552f934dbee8: Bug 1422014 - Resend option in netmonitor. r=Honza
tanhengyeow <E0032242@u.nus.edu> - Mon, 18 Mar 2019 11:55:24 +0000 - rev 506545
Push 138 by mtabara@mozilla.com at Wed, 20 Mar 2019 18:12:49 +0000
Bug 1422014 - Resend option in netmonitor. r=Honza Add resend option in the context menu of netmonitor. Differential Revision: https://phabricator.services.mozilla.com/D20091
cee5e58bcf61c6044ff4ac03a54baf9bf38dc3bc: Bug 1534956 - Add Cristiano's facebook page to tp6-m r=Bebe
Marian Raiciof <mraiciof@mozilla.com> - Fri, 15 Mar 2019 11:46:22 +0000 - rev 506544
Push 138 by mtabara@mozilla.com at Wed, 20 Mar 2019 18:12:49 +0000
Bug 1534956 - Add Cristiano's facebook page to tp6-m r=Bebe Differential Revision: https://phabricator.services.mozilla.com/D23317
2c02713dbf4590fdc2f59b741758aa63b494cfb3: Merge mozilla-central to autoland. a=merge CLOSED TREE
Brindusan Cristian <cbrindusan@mozilla.com> - Mon, 18 Mar 2019 13:25:50 +0200 - rev 506543
Push 138 by mtabara@mozilla.com at Wed, 20 Mar 2019 18:12:49 +0000
Merge mozilla-central to autoland. a=merge CLOSED TREE
891a30b8eee20648df8b62217304fb0a0636349d: Update configs. IGNORE BROKEN CHANGESETS CLOSED TREE NO BUG a=release ba=release
ffxbld <release@mozilla.com> - Mon, 18 Mar 2019 11:01:13 +0000 - rev 506542
Push 138 by mtabara@mozilla.com at Wed, 20 Mar 2019 18:12:49 +0000
Update configs. IGNORE BROKEN CHANGESETS CLOSED TREE NO BUG a=release ba=release
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 tip