searching for reviewer(hiro)
e98876a6813552157c6897eb519db62b664c1d37: Bug 1511625 - Add a meta viewport to a test so that it doesn't perma-fail on Android. r=hiro
Emilio Cobos Álvarez <emilio@crisal.io> - Tue, 18 Jun 2019 23:19:29 +0000 - rev 479180
Push 36173 by rgurzau@mozilla.com at Wed, 19 Jun 2019 15:50:11 +0000
Bug 1511625 - Add a meta viewport to a test so that it doesn't perma-fail on Android. r=hiro Differential Revision: https://phabricator.services.mozilla.com/D35279
421c96010e6734faeb6ec0cbdb04e86c5f0fffb6: Bug 1554790 - Add a reftest-resolution attribute. r=kats,hiro
Botond Ballo <botond@mozilla.com> - Tue, 11 Jun 2019 02:22:02 +0000 - rev 478154
Push 36137 by cbrindusan@mozilla.com at Tue, 11 Jun 2019 09:40:01 +0000
Bug 1554790 - Add a reftest-resolution attribute. r=kats,hiro Differential Revision: https://phabricator.services.mozilla.com/D32774
2b90bc2a97f4c1e6c6ee8e1c519d4deaadc8f485: Bug 1555548 - Send other transform-like properties as non-animating animation into compositor. r=hiro
Boris Chiou <boris.chiou@gmail.com> - Thu, 06 Jun 2019 18:29:46 +0000 - rev 477718
Push 36121 by dvarga@mozilla.com at Fri, 07 Jun 2019 09:47:19 +0000
Bug 1555548 - Send other transform-like properties as non-animating animation into compositor. r=hiro Not only animating transform-like properties, but also non-animating ones have to be passed into the compositor, so the final transform matrix could take them into account (on the compositor). Differential Revision: https://phabricator.services.mozilla.com/D33580
83bd68a2767e6ad69493f5e6cb39bce54e4f3174: Bug 1555548 - Move pref into StaticPrefList. r=hiro
Boris Chiou <boris.chiou@gmail.com> - Thu, 06 Jun 2019 18:25:08 +0000 - rev 477717
Push 36121 by dvarga@mozilla.com at Fri, 07 Jun 2019 09:47:19 +0000
Bug 1555548 - Move pref into StaticPrefList. r=hiro So we can use StaticPrefs::layout_css_individual_transform_enabled() in the next patch. Differential Revision: https://phabricator.services.mozilla.com/D33579
3a41c4ed8bf3c803a2e2ee922ab3813631685b79: Bug 1554790 - Add a reftest-resolution attribute. r=kats,hiro
Botond Ballo <botond@mozilla.com> - Wed, 05 Jun 2019 01:53:45 +0000 - rev 476998
Push 36115 by shindli@mozilla.com at Thu, 06 Jun 2019 09:29:49 +0000
Bug 1554790 - Add a reftest-resolution attribute. r=kats,hiro Differential Revision: https://phabricator.services.mozilla.com/D32774
73cfd3c761d388ac2fb762e107f4d2994a196dc8: Bug 1554794 - Add PresShell::UsesMobileViewportSizing() and use it in place of GetIsViewportOverridden() where appropriate. r=kats,hiro
Botond Ballo <botond@mozilla.com> - Tue, 28 May 2019 13:31:59 +0000 - rev 475942
Push 36080 by nerli@mozilla.com at Wed, 29 May 2019 09:48:47 +0000
Bug 1554794 - Add PresShell::UsesMobileViewportSizing() and use it in place of GetIsViewportOverridden() where appropriate. r=kats,hiro With desktop zooming, we need to separate the concepts of "may have a distinct visual viewport" from "has mobile viewport sizing logic applied to it". This can be thought of as completing the disentanglement of zooming from meta viewport support started in bug 1459260. Differential Revision: https://phabricator.services.mozilla.com/D32770
6c2047bc2f3e9e2e165d0c03177ae4212a912077: Bug 1553227 - Remove old CSS scroll snap implementation. r=hiro
Emilio Cobos Álvarez <emilio@crisal.io> - Tue, 21 May 2019 22:51:54 +0000 - rev 474861
Push 36047 by nerli@mozilla.com at Wed, 22 May 2019 03:40:58 +0000
Bug 1553227 - Remove old CSS scroll snap implementation. r=hiro This will save us some time from figuring out what's the best thing to do in bug 1552587, so that other patches I have in flight (mainly bug 1552708) can land, since we cannot add a single byte to nsStyleDisplay right now otherwise. The code removed here is well isolated and not that complicated, so it seems to me that should be easy to bring back should we have an emergency (and I commit to doing that while preserving the nsStyleDisplay size limit if we need to :)). Differential Revision: https://phabricator.services.mozilla.com/D32026
6ceb38a8197408f055b05b205bc412f2c77850a9: Bug 1429299 - Part 4: Make offset-distance animatable. r=hiro
Boris Chiou <boris.chiou@gmail.com> - Mon, 20 May 2019 23:42:56 +0000 - rev 474643
Push 36042 by dvarga@mozilla.com at Tue, 21 May 2019 04:19:40 +0000
Bug 1429299 - Part 4: Make offset-distance animatable. r=hiro Use ComputedValue to animate offset-distance. Differential Revision: https://phabricator.services.mozilla.com/D30584
0e25f7b0790b67bcd5614384def4f7158aa3048f: Bug 1253476 - Run microtask checkpoint for updating timing after updating all timelines; r=hiro
Brian Birtles <birtles@gmail.com> - Mon, 20 May 2019 05:22:03 +0000 - rev 474485
Push 36040 by rgurzau@mozilla.com at Mon, 20 May 2019 13:43:21 +0000
Bug 1253476 - Run microtask checkpoint for updating timing after updating all timelines; r=hiro According to the procedure to update animations and send events[1] the UA should update all timelines first and _then_ run a microtask checkpoint. As a result, when we run callbacks for the finished promise on an Animation they should see the fully up-to-date state of all animations, regardless of which timeline they are attached to. However, that is currently not the case since we run a microtask checkpoint after updating each individual timeline. This difference will become more significant later in this patch series when we introduce another step--removing replaced animations--that _also_ should happen before we run the microtask checkpoint (so that the promise callbacks always see a fully-up-to-date state). This patch makes our handling a little more in line with the spec. It's not quite the same because it's possible there may be other refresh driver observers that trigger a microtask checkpoint in between ticking the different timelines but that case is expected to be rare and fixing it would require maintaining a separate queue for timeline observers that we run after all other observers-- so it is probably not necessary to fix that case at this stage. The test added in this patch fails without the code changes in this patch. [1] https://drafts.csswg.org/web-animations-1/#update-animations-and-send-events Differential Revision: https://phabricator.services.mozilla.com/D30319
861caf0b6714f5a119f04ba3e1e9badf44986e60: Bug 1253476 - Make Animation::Tick do finish actions synchronously; r=hiro
Brian Birtles <birtles@gmail.com> - Mon, 20 May 2019 05:20:17 +0000 - rev 474484
Push 36040 by rgurzau@mozilla.com at Mon, 20 May 2019 13:43:21 +0000
Bug 1253476 - Make Animation::Tick do finish actions synchronously; r=hiro Animation::UpdateTiming takes a SyncNotifyFlag parameter. This is passed to UpdateFinishedState where it determines how we handle finish actions. If it is async we queue a microtask where we re-evaluate if the animation is finished or not before queuing events / resolving promises. That allows code like the following to _not_ trigger finish events: ``` const animation = elem.animate({...}, 1000); animation.currentTime += 1000; animation.effect.updateTiming({ duration: 2000 }); ``` (Since the check that the animation is finished will run in a microtask _after_ the call to updateTiming.) When the flag is "sync" we still don't _actually_ run the finish actions entirely synchronously: the finished promise is resolved synchronously, but resolving a promise actually queues a microtask for each callback. Likewise, the finish event is queued synchronously, but not dispatched. Since there should be no opportunity for script to run between when we call Animation::Tick and when we run the next microtask checkpoint (currently at the end of DocumentTimeline::WillRefresh but that will change slightly in the next patch in this series) there is no need to introduce the extra "async" microtask for re-evaluating an animation's finished state. Instead it should be possible to use the "sync" finishing behavior. Such a change should be unobservable to Web content but will reduce indirection somewhat. Differential Revision: https://phabricator.services.mozilla.com/D30318
6e5b24c61e3aa7b01cebef924128bdf3b8019d7c: Bug 1253476 - Use in-class member initializers in Animation.h; r=hiro
Brian Birtles <birtles@gmail.com> - Mon, 20 May 2019 05:20:07 +0000 - rev 474483
Push 36040 by rgurzau@mozilla.com at Mon, 20 May 2019 13:43:21 +0000
Bug 1253476 - Use in-class member initializers in Animation.h; r=hiro The in-class initializers are easier to maintain since you don't have to try and match them up with the constructor initializer list (including matching the order). Differential Revision: https://phabricator.services.mozilla.com/D30317
eeb6dd82b7c1a9fc36610bfe1ccecdf93c356677: Bug 1552387 - Traverse and unlink EffectSet properties on non-HTML/SVG elements too; r=hiro
Brian Birtles <birtles@gmail.com> - Fri, 17 May 2019 04:49:38 +0000 - rev 474299
Push 36027 by shindli@mozilla.com at Fri, 17 May 2019 16:24:38 +0000
Bug 1552387 - Traverse and unlink EffectSet properties on non-HTML/SVG elements too; r=hiro The tests added in this patch do not fail any of their assertions with or without the code changes in this patch. However, without the code changes in this patch they will both fail due to reported memory leaks. Differential Revision: https://phabricator.services.mozilla.com/D31577
df182ef2d4e5a7fe9b44280139ae0fa0d5154d16: Bug 1522443 - Avoid intermittent failure of viewport-no-resize-event-on-overflow-recalc.html. r=hiro
Botond Ballo <botond@mozilla.com> - Wed, 15 May 2019 23:43:50 +0000 - rev 474009
Push 36020 by dvarga@mozilla.com at Thu, 16 May 2019 04:15:07 +0000
Bug 1522443 - Avoid intermittent failure of viewport-no-resize-event-on-overflow-recalc.html. r=hiro Differential Revision: https://phabricator.services.mozilla.com/D31344
9f6e01596b42c2a9648dd4a74f8c0956724ebe6a: Bug 1550403 - Drop call to Servo_Property_IsAnimatable in SMILCSSProperty::IsPropertyAnimatable; r=hiro
Brian Birtles <birtles@gmail.com> - Thu, 09 May 2019 06:42:17 +0000 - rev 473180
Push 35990 by nerli@mozilla.com at Thu, 09 May 2019 15:34:57 +0000
Bug 1550403 - Drop call to Servo_Property_IsAnimatable in SMILCSSProperty::IsPropertyAnimatable; r=hiro As per bug 1353918 comment 13, all these properties are animatable on the Servo side so we no longer need this check. Differential Revision: https://phabricator.services.mozilla.com/D30458
6d0c3c2fda714601e6fb61019ed2a9b9db0eeb81: Bug 1477610 - Update bug reference in disabled annotation of viewport-resize-event-on-load-overflowing-page.html. r=hiro
Botond Ballo <botond@mozilla.com> - Thu, 09 May 2019 03:57:15 +0000 - rev 473171
Push 35990 by nerli@mozilla.com at Thu, 09 May 2019 15:34:57 +0000
Bug 1477610 - Update bug reference in disabled annotation of viewport-resize-event-on-load-overflowing-page.html. r=hiro Differential Revision: https://phabricator.services.mozilla.com/D30418
a7ec57d41cbbaf766097d735ba76908a2a587e16: Bug 1477610 - Wait for the load event before running viewport-unscaled-size-iframe.html. r=hiro
Botond Ballo <botond@mozilla.com> - Thu, 09 May 2019 03:57:08 +0000 - rev 473170
Push 35990 by nerli@mozilla.com at Thu, 09 May 2019 15:34:57 +0000
Bug 1477610 - Wait for the load event before running viewport-unscaled-size-iframe.html. r=hiro This ensures that the iframe is loaded by the time we query its visual viewport size. Differential Revision: https://phabricator.services.mozilla.com/D30417
695609f420a1f42efb91dbd552d4e75e1dc00c3f: Bug 1477610 - Make sure a resize during page load doesn't get mis-identified as a resize caused by a subsequent layout change. r=hiro
Botond Ballo <botond@mozilla.com> - Thu, 09 May 2019 03:56:58 +0000 - rev 473169
Push 35990 by nerli@mozilla.com at Thu, 09 May 2019 15:34:57 +0000
Bug 1477610 - Make sure a resize during page load doesn't get mis-identified as a resize caused by a subsequent layout change. r=hiro Differential Revision: https://phabricator.services.mozilla.com/D30416
6f7cd5ebb041ea3c4de4206d5489883e239ffbb5: Bug 1477610 - Flush layout when reporting the visual viewport size via the Visual Viewport API. r=hiro
Botond Ballo <botond@mozilla.com> - Thu, 09 May 2019 03:56:41 +0000 - rev 473167
Push 35990 by nerli@mozilla.com at Thu, 09 May 2019 15:34:57 +0000
Bug 1477610 - Flush layout when reporting the visual viewport size via the Visual Viewport API. r=hiro Differential Revision: https://phabricator.services.mozilla.com/D29089
cf7b6547cfb26608ba79093ed78f85a56dfbfd56: Bug 1549589 - scroll-snap-coordinate shouldn't use NotInitial. r=hiro
Emilio Cobos Álvarez <emilio@crisal.io> - Mon, 06 May 2019 21:31:16 +0000 - rev 472786
Push 35978 by shindli@mozilla.com at Tue, 07 May 2019 09:44:39 +0000
Bug 1549589 - scroll-snap-coordinate shouldn't use NotInitial. r=hiro The initial value for this is indeed `none` (and thus empty). The Rust code was confused. This property is disabled by default these days, and I think the get_initial_value() function, which is what could get confused, is not called for this property, so I think this shouldn't be observable. Differential Revision: https://phabricator.services.mozilla.com/D30124
6ccf33c9e56e44937858a86890a65c4296861d98: Bug 1545707 - Rework hidden-container-001.html CSS transitions tests; r=hiro
Brian Birtles <birtles@gmail.com> - Mon, 22 Apr 2019 00:53:49 +0000 - rev 470322
Push 35898 by shindli@mozilla.com at Mon, 22 Apr 2019 09:39:21 +0000
Bug 1545707 - Rework hidden-container-001.html CSS transitions tests; r=hiro This behavior is not actually clearly specified yet. See: https://github.com/w3c/csswg-drafts/issues/3790 But when it is specified it will most likely be specified in terms of HTML's "being rendered" definition: https://html.spec.whatwg.org/#being-rendered I had planned to specify this behavior before updating these tests but I need to update them first in order to add the ::marker tests for this bug. Differential Revision: https://phabricator.services.mozilla.com/D28174
84ef7b7abb02f73bf24b1d14c45bbb70093318b0: Bug 1545781 - One of the versions of EffectCompositor::PreTraverse is dead code. r=hiro
Emilio Cobos Álvarez <emilio@crisal.io> - Fri, 19 Apr 2019 22:01:00 +0000 - rev 470261
Push 35891 by rgurzau@mozilla.com at Sat, 20 Apr 2019 09:35:22 +0000
Bug 1545781 - One of the versions of EffectCompositor::PreTraverse is dead code. r=hiro Callers were removed in bug 1540220. Differential Revision: https://phabricator.services.mozilla.com/D28196
42c40172ca0e497ebfac94473a97ab9460425926: Bug 1545689 - Fix disconnected-element-001.html to reflect that addDiv adds its element to the document; r=hiro
Brian Birtles <birtles@gmail.com> - Fri, 19 Apr 2019 09:09:49 +0000 - rev 470195
Push 35890 by dluca@mozilla.com at Fri, 19 Apr 2019 21:44:39 +0000
Bug 1545689 - Fix disconnected-element-001.html to reflect that addDiv adds its element to the document; r=hiro The initial version of this test assumed that the `addDiv` utility function merely created a <div> without attaching it to the document. That's not the case, however, and so a number of the assumptions in this test are wrong. This patch reworks this test to reflect what `addDiv` does. Differential Revision: https://phabricator.services.mozilla.com/D28173
928f042ca74e2b75be1eace7fcc138ba571fd3a0: Bug 1541767 - Drop animations on an element before removing it from the document; r=hiro
Brian Birtles <birtles@gmail.com> - Thu, 18 Apr 2019 06:56:40 +0000 - rev 469997
Push 35884 by apavel@mozilla.com at Thu, 18 Apr 2019 21:35:00 +0000
Bug 1541767 - Drop animations on an element before removing it from the document; r=hiro See the previous patch in this series for a detailed explanation of why this is necessary. The test included in this patch is from some work I am doing to rewrite the CSS transitions web-platform-tests. As a result, it includes more than is strictly related to this issue addressed by this bug. Without the code changes in this patch the fourth test onwards, "Transitions are canceled when an element is removed from the document", will timeout waiting for the transitioncancel event. Differential Revision: https://phabricator.services.mozilla.com/D28022
0d047d6f122b7fec64ce39da784f10e181ce8d66: Bug 1541767 - Don't post animation restyles when unbinding an element; r=hiro
Brian Birtles <birtles@gmail.com> - Thu, 18 Apr 2019 06:49:25 +0000 - rev 469996
Push 35884 by apavel@mozilla.com at Thu, 18 Apr 2019 21:35:00 +0000
Bug 1541767 - Don't post animation restyles when unbinding an element; r=hiro Currently we avoid posting animation restyles when unbinding an element by removing the element from the document before deleting its animation collections. As a result, when canceled animations go to post a restyle, they can't find a pres context and give up posting a restyle. However, this is problematic for two reasons: * It means we can't remove such canceled animations from the PendingAnimationTracker if they are present there (i.e. it regresses the fix from bug 1223445). * It means we can't post cancel events for such animations/transitions since we can't lookup the appropriate AnimationEventDispatcher. In the next patch in this series we will change that order to fix the above problems but before we do that, we need to introduce another mechanism to make sure that we don't post restyles when unbinding an element or else we will regress bug 1396041. This patch does that by introducing a flag which causes us to not post restyles when we are doing DOM surgery. For all other cases we actually _do_ need to post restyles in order to update the style correctly. Without this patch, layout/style/crashtests/1396041.html would fail after applying the next patch in this series. Differential Revision: https://phabricator.services.mozilla.com/D28021
a751128e51f71ddd7df3eaa1ba8c5c34b6876e31: Bug 1541767 - Make Animation::Cancel line up with the spec a little better; r=hiro
Brian Birtles <birtles@gmail.com> - Thu, 18 Apr 2019 06:25:54 +0000 - rev 469995
Push 35884 by apavel@mozilla.com at Thu, 18 Apr 2019 21:35:00 +0000
Bug 1541767 - Make Animation::Cancel line up with the spec a little better; r=hiro Animation::Cancel calls UpdateTiming() which in turns runs the procedure to update the finished state. However, the spec[1] doesn't require that. Furthermore, calling UpdateTiming here hides the fact that we end up triggering a restyle. It would be better to move the parts of UpdateTiming we require into Cancel itself so that we align better with the spec and to make it a bit more clear what side-effects of UpdateTiming we actually rely on. [1] https://drafts.csswg.org/web-animations-1/#cancel-an-animation Differential Revision: https://phabricator.services.mozilla.com/D28020
67900e2680ff84192ebfd3b5d0c5124ddc49c624: Bug 1541767 - Drop Animation::CancelNoUpdate; r=hiro
Brian Birtles <birtles@gmail.com> - Thu, 18 Apr 2019 06:24:52 +0000 - rev 469994
Push 35884 by apavel@mozilla.com at Thu, 18 Apr 2019 21:35:00 +0000
Bug 1541767 - Drop Animation::CancelNoUpdate; r=hiro CancelNoUpdate actually can and does trigger restyles via its call to KeyframeEffect::NotifyAnimationTimingUpdated so at very least its name is wrong. Furthermore, we actually want canceling to trigger restyles in most cases since when an animation is canceled we need to trigger a subsequent restyle to apply the (no-longer-animated) result. This wasn't necessary when CancelNoUpdate was first introduced but since then we have introduced the Servo style engine where we use a separate traversal to apply the result from creating/deleting/modifying animations. This change will mean that we now trigger a "layer" restyle when canceling an animation when we previously didn't. That, however, seems more correct if anything. This patch also makes CancelFromStyle no longer virtual since it doesn't seem necessary anymore (perhaps because we now point to the concrete type: CSSAnimation/CSSTransition from nsAnimationManager/nsTransitionManager whereas previously we didn't). Differential Revision: https://phabricator.services.mozilla.com/D28019
79686ffd6bacff33b13340cb5f7daeb32e366266: Bug 1526847 - Let ComputeSuitableScaleForAnimation check other transform-like properties. r=hiro
Boris Chiou <boris.chiou@gmail.com> - Fri, 12 Apr 2019 21:43:23 +0000 - rev 469351
Push 35865 by apavel@mozilla.com at Sat, 13 Apr 2019 21:44:49 +0000
Bug 1526847 - Let ComputeSuitableScaleForAnimation check other transform-like properties. r=hiro Check all transform-like properties which may affect the scaling factors when computing the suitable scale for animations. Differential Revision: https://phabricator.services.mozilla.com/D19526
a4aa09eccb1b179289e5fef95ffaaa638e6e4bac: Bug 1542933 - Do not attempt minimum scale computation with empty overflow rect. r=hiro
Botond Ballo <botond@mozilla.com> - Wed, 10 Apr 2019 22:43:20 +0000 - rev 468921
Push 35854 by aciure@mozilla.com at Thu, 11 Apr 2019 09:50:57 +0000
Bug 1542933 - Do not attempt minimum scale computation with empty overflow rect. r=hiro Differential Revision: https://phabricator.services.mozilla.com/D27003
6f0b0ab56a478e99853a465ceaa7a5d8c7e2b1b8: Bug 1533968 - Don't add animations to layer for TYPE_TABLE_BACKRGOUND_COLOR. r=hiro
Boris Chiou <boris.chiou@gmail.com> - Wed, 10 Apr 2019 18:50:34 +0000 - rev 468905
Push 35854 by aciure@mozilla.com at Thu, 11 Apr 2019 09:50:57 +0000
Bug 1533968 - Don't add animations to layer for TYPE_TABLE_BACKRGOUND_COLOR. r=hiro nsDisplayTableBackgroundColor inherits from nsDisplayBackgroundColor, and both display item types are mapped to background_color property. However, nsDisplayTableBackgroundColor is not animated on the compositor, so we shouldn't add animations for TYPE_TABLE_BACKRGOUND_COLOR. It seems the test case has a weird timeout in Android test-verify-opt. I checked the live.log and the tests are passed, but got a final time-out. It is not related to our change because this still happens if we skip the test, and I saw that other intermittent bugs have the same issue. Differential Revision: https://phabricator.services.mozilla.com/D24780
e1fa16165c528ccb201e8f9e2a24ce6833aeeded: Bug 1540220 - Stop uselessly calling EffectCompositor from ResolveStyleLazily. r=hiro
Emilio Cobos Álvarez <emilio@crisal.io> - Tue, 09 Apr 2019 18:05:08 +0000 - rev 468611
Push 35843 by nbeleuzu@mozilla.com at Tue, 09 Apr 2019 22:08:13 +0000
Bug 1540220 - Stop uselessly calling EffectCompositor from ResolveStyleLazily. r=hiro It's the caller's responsibility to have up-to-date styles, and nsComputedDOMStyle (which is the only of those callers that could ever care about EffectCompositor stuff) already does it. There's no need to explicitly update animation rules from here, since it would only have a difference for display: none subtrees anyway (otherwise we re-use the cached style already in the element before having a chance to process the potential animation restyles). My guess is that this was just copy-pasta from other functions. This doesn't break any test. Differential Revision: https://phabricator.services.mozilla.com/D25458
09351cbff6841a3bf5c080ce3686acc19923f776: Bug 1516056 - Prevent zooming in marionette test_typing.py testcase. r=hiro
Botond Ballo <botond@mozilla.com> - Mon, 08 Apr 2019 23:36:40 +0000 - rev 468450
Push 35838 by nerli@mozilla.com at Tue, 09 Apr 2019 09:54:40 +0000
Bug 1516056 - Prevent zooming in marionette test_typing.py testcase. r=hiro This avoids the testcase running into bug 1516722. Depends on D20284 Differential Revision: https://phabricator.services.mozilla.com/D20285
d810f579f67daa0f2dae79630818f508c64e2e62: Bug 1533594 - Set performance warning by a property set. r=hiro
Boris Chiou <boris.chiou@gmail.com> - Thu, 21 Mar 2019 17:40:11 +0000 - rev 465478
Push 35741 by apavel@mozilla.com at Fri, 22 Mar 2019 09:56:25 +0000
Bug 1533594 - Set performance warning by a property set. r=hiro We want to set the performance warning by a property set, so update it. Besides, add more tests for individual transforms (translate, rotate, scale). Differential Revision: https://phabricator.services.mozilla.com/D19633
993bbf845ef0d2bb00817a112683c84df4b08cd6: Bug 1536392 - Disable multiple transform-like properties animation at 5s on GeckoView. r=hiro
Boris Chiou <boris.chiou@gmail.com> - Wed, 20 Mar 2019 00:12:50 +0000 - rev 465151
Push 35732 by opoprus@mozilla.com at Wed, 20 Mar 2019 10:52:37 +0000
Bug 1536392 - Disable multiple transform-like properties animation at 5s on GeckoView. r=hiro If we have an animation with multiple transform-like properties, it seems getOMTAStyle(transform) returns an empty string at 50% on Android x86_64 opt with e10s, so we cannot pass this test case. We temporarily disable this test case on this platform. Differential Revision: https://phabricator.services.mozilla.com/D24103
08126c1f53fe82ab685bd3e75e97ce7bf516a3d9: Bug 1425837 - Part 9: Throttle transform-like properties animations without 0% or 100% keyframe. r=hiro
Boris Chiou <boris.chiou@gmail.com> - Mon, 18 Mar 2019 18:05:06 +0000 - rev 464931
Push 35729 by opoprus@mozilla.com at Tue, 19 Mar 2019 16:30:13 +0000
Bug 1425837 - Part 9: Throttle transform-like properties animations without 0% or 100% keyframe. r=hiro We should also throttle other transform-like animations which can run on the compositor thread, on visibility hidden element without 0% or 100% keyframe. Depends on D22568 Differential Revision: https://phabricator.services.mozilla.com/D19634
9fe743aa6c94f49346902934f40f8f55663bc54d: Bug 1425837 - Part 8: Test that individual transforms run on the compositor thread. r=hiro,birtles
Boris Chiou <boris.chiou@gmail.com> - Mon, 18 Mar 2019 18:05:04 +0000 - rev 464930
Push 35729 by opoprus@mozilla.com at Tue, 19 Mar 2019 16:30:13 +0000
Bug 1425837 - Part 8: Test that individual transforms run on the compositor thread. r=hiro,birtles This also adds the missing preference in test_transition_per_property.html. Depends on D22567 Differential Revision: https://phabricator.services.mozilla.com/D22568
af39dc228d19a34892e32faab8fb105352708099: Bug 1425837 - Part 7: Drop the hard-code disabling compositor animations on individual transforms. r=hiro,birtles
Boris Chiou <boris.chiou@gmail.com> - Mon, 18 Mar 2019 18:05:02 +0000 - rev 464929
Push 35729 by opoprus@mozilla.com at Tue, 19 Mar 2019 16:30:13 +0000
Bug 1425837 - Part 7: Drop the hard-code disabling compositor animations on individual transforms. r=hiro,birtles Drop the hack which prevents individual transform running on the compositor thread. Depends on D22566 Differential Revision: https://phabricator.services.mozilla.com/D22567
066e7dffe044684ddb7b2c667d7753b8ffab1e93: Bug 1425837 - Part 6: Add individual transform properties into compositor animation list. r=hiro
Boris Chiou <boris.chiou@gmail.com> - Mon, 18 Mar 2019 18:05:00 +0000 - rev 464928
Push 35729 by opoprus@mozilla.com at Tue, 19 Mar 2019 16:30:13 +0000
Bug 1425837 - Part 6: Add individual transform properties into compositor animation list. r=hiro Now, its time to let individual transform run on the compositor thread. Depends on D19636 Differential Revision: https://phabricator.services.mozilla.com/D22566
067a9dac440ab23f16c8034f104911a80773705a: Bug 1425837 - Part 5: AnimationInfo::HasTransformAnimation should check other OMTA transform-like properties r=hiro
Boris Chiou <boris.chiou@gmail.com> - Mon, 18 Mar 2019 18:04:58 +0000 - rev 464927
Push 35729 by opoprus@mozilla.com at Tue, 19 Mar 2019 16:30:13 +0000
Bug 1425837 - Part 5: AnimationInfo::HasTransformAnimation should check other OMTA transform-like properties r=hiro This function was added for B2G actually, to check if the layer has OMTA for painting high-res layer. However, It's worth to let it also check other OMTA transform-like properties. Depends on D22565 Differential Revision: https://phabricator.services.mozilla.com/D19636
b27d18cccc623d49dfcd89aa07890ab940d859f5: Bug 1425837 - Part 4: Implement compositor animations on translate/rotate/scale. r=hiro,birtles
Boris Chiou <boris.chiou@gmail.com> - Mon, 18 Mar 2019 18:04:50 +0000 - rev 464926
Push 35729 by opoprus@mozilla.com at Tue, 19 Mar 2019 16:30:13 +0000
Bug 1425837 - Part 4: Implement compositor animations on translate/rotate/scale. r=hiro,birtles On the sender side of transactions, we have to convert the individual transforms to the proper types in layers::Animations, and this includes SetAnimatable and the definition in LayersMessages. On the compositor side (i.e. received side of transactions). Basically, we convert the list of layers::Animation into a list of `PropertyAnimationGroup`, which is an intermediate value. And then use this list to do interpolation for each property in `SampleAnimationForEachNode`, which will return a list of `RefPtr<RawServoAnimationValue>`. Depends on D23062 Differential Revision: https://phabricator.services.mozilla.com/D22565
5d416b07c9b9886d7456e9e209ed93247e497af8: Bug 1425837 - Part 2: Factor out the conversion from ServoAnimationValue into Matrix4x4. r=hiro
Boris Chiou <boris.chiou@gmail.com> - Mon, 18 Mar 2019 18:04:46 +0000 - rev 464924
Push 35729 by opoprus@mozilla.com at Tue, 19 Mar 2019 16:30:13 +0000
Bug 1425837 - Part 2: Factor out the conversion from ServoAnimationValue into Matrix4x4. r=hiro Both layers and web-render use this function, so we factor it out. Depends on D22562 Differential Revision: https://phabricator.services.mozilla.com/D22563
07a1ab95598e298d92faf62534869ea45e8cd979: Bug 1425837 - Part 1: Move ToAnimationValue into AnimationValue. r=hiro
Boris Chiou <boris.chiou@gmail.com> - Mon, 18 Mar 2019 18:04:44 +0000 - rev 464923
Push 35729 by opoprus@mozilla.com at Tue, 19 Mar 2019 16:30:13 +0000
Bug 1425837 - Part 1: Move ToAnimationValue into AnimationValue. r=hiro It seems this function uses some FFIs to generate the AnimationValue, We could move it into AnimationValue class, although what we really need is RefPtr<ServoAnimationValue>. Maybe we should use AnimationValue everywhere, instead of the Servo type. This could be done by other patches. Differential Revision: https://phabricator.services.mozilla.com/D22562
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 464767
Push 35724 by rgurzau@mozilla.com at Mon, 18 Mar 2019 21:36:40 +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 464766
Push 35724 by rgurzau@mozilla.com at Mon, 18 Mar 2019 21:36:40 +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 464765
Push 35724 by rgurzau@mozilla.com at Mon, 18 Mar 2019 21:36:40 +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 464764
Push 35724 by rgurzau@mozilla.com at Mon, 18 Mar 2019 21:36:40 +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 464763
Push 35724 by rgurzau@mozilla.com at Mon, 18 Mar 2019 21:36:40 +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 464762
Push 35724 by rgurzau@mozilla.com at Mon, 18 Mar 2019 21:36:40 +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 464761
Push 35724 by rgurzau@mozilla.com at Mon, 18 Mar 2019 21:36:40 +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 464760
Push 35724 by rgurzau@mozilla.com at Mon, 18 Mar 2019 21:36:40 +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
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 464758
Push 35724 by rgurzau@mozilla.com at Mon, 18 Mar 2019 21:36:40 +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