searching for reviewer(hiro)
2d5ac5ef8f33dfd5ed0529c90f30ee64dd16d31a: Bug 1567108 - Test. r=hiro,emilio
Hiroyuki Ikezoe <hikezoe.birchill@mozilla.com> - Fri, 19 Jul 2019 05:20:48 +0200 - rev 483614
Push 113734 by nbeleuzu@mozilla.com at Sat, 20 Jul 2019 21:45:35 +0000
Bug 1567108 - Test. r=hiro,emilio Differential Revision: https://phabricator.services.mozilla.com/D38601
81ab59a7247cae2188b7ad23b65389acf02f1600: Bug 1567108 - Remove a FIXME that is not relevant. r=hiro
Emilio Cobos Álvarez <emilio@crisal.io> - Fri, 19 Jul 2019 04:36:53 +0000 - rev 483613
Push 113734 by nbeleuzu@mozilla.com at Sat, 20 Jul 2019 21:45:35 +0000
Bug 1567108 - Remove a FIXME that is not relevant. r=hiro We get hints for both frames, so we tag both. Depends on D38599 Differential Revision: https://phabricator.services.mozilla.com/D38600
bb43baa7d8c94252383260962fbad0c9ddf5af03: Bug 1567108 - Revert RestyleManager changes from bug 1527210. r=hiro
Emilio Cobos Álvarez <emilio@crisal.io> - Fri, 19 Jul 2019 04:39:16 +0000 - rev 483612
Push 113734 by nbeleuzu@mozilla.com at Sat, 20 Jul 2019 21:45:35 +0000
Bug 1567108 - Revert RestyleManager changes from bug 1527210. r=hiro They're wrong. When a property that affects the parent frame changes, we get a hint for both frames. This fixes this bug. Depends on D38598 Differential Revision: https://phabricator.services.mozilla.com/D38599
47ff979267bedeb347c2597068dc7e5009cb1845: Bug 1567108 - Fix bug 1527210 in a simpler way. r=hiro
Emilio Cobos Álvarez <emilio@crisal.io> - Fri, 19 Jul 2019 04:38:53 +0000 - rev 483611
Push 113734 by nbeleuzu@mozilla.com at Sat, 20 Jul 2019 21:45:35 +0000
Bug 1567108 - Fix bug 1527210 in a simpler way. r=hiro This is IMO the right RestyleManager change for what bug 1527210 tried to fix. We need to apply the animation hints to the primary frame, not the style frame. The other non-RestyleManager bits of that bug still apply and look fine to me. Differential Revision: https://phabricator.services.mozilla.com/D38598
9f45982e7800871078d5b707bcfcc6c12000bbc0: Bug 1559690 - Actually make scrollport events use the event loop, since using the same scroll event mechanism breaks too much stuff. r=hiro
Emilio Cobos Álvarez <emilio@crisal.io> - Tue, 25 Jun 2019 11:12:53 +0200 - rev 480156
Push 113534 by rgurzau@mozilla.com at Wed, 26 Jun 2019 22:06:25 +0000
Bug 1559690 - Actually make scrollport events use the event loop, since using the same scroll event mechanism breaks too much stuff. r=hiro The issue with using the same mechanism as scroll events is that overflow events that result from a layout flush from the refresh driver tick don't happen until the _next_ refresh driver tick. That's bad and causes a few tests that don't wait enough to fail. I guess the next alternative is what PostDOMEvent uses, which is just dispatch to the event loop. This is actually green and also fixes the bug for the same reason. Differential Revision: https://phabricator.services.mozilla.com/D35769
fdb96c16d976a045ee5a96d2c6b866e60eded1a9: Bug 1559690 - Make scroll port events use the same mechanism as scroll events. r=hiro
Emilio Cobos Álvarez <emilio@crisal.io> - Sat, 22 Jun 2019 18:03:25 +0200 - rev 480155
Push 113534 by rgurzau@mozilla.com at Wed, 26 Jun 2019 22:06:25 +0000
Bug 1559690 - Make scroll port events use the same mechanism as scroll events. r=hiro This prevents them from being called from layout and is more similar to what WillPaintObservers did. Differential Revision: https://phabricator.services.mozilla.com/D35604
ae4b3c9f8ee55b431b4b9f7a7f454c27416a82bb: Bug 1559690 - Move scroll event declarations to nsGfxScrollFrame.cpp r=hiro
Emilio Cobos Álvarez <emilio@crisal.io> - Sat, 22 Jun 2019 17:39:08 +0200 - rev 480154
Push 113534 by rgurzau@mozilla.com at Wed, 26 Jun 2019 22:06:25 +0000
Bug 1559690 - Move scroll event declarations to nsGfxScrollFrame.cpp r=hiro Differential Revision: https://phabricator.services.mozilla.com/D35603
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 113467 by rgurzau@mozilla.com at Wed, 19 Jun 2019 15:55:23 +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 478175
Push 113407 by cbrindusan@mozilla.com at Tue, 11 Jun 2019 09:45:25 +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 477735
Push 113372 by dvarga@mozilla.com at Fri, 07 Jun 2019 10:07:35 +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 477734
Push 113372 by dvarga@mozilla.com at Fri, 07 Jun 2019 10:07:35 +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 477498
Push 113351 by shindli@mozilla.com at Thu, 06 Jun 2019 10:13:05 +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 475947
Push 113240 by nerli@mozilla.com at Wed, 29 May 2019 09:56:33 +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 474894
Push 113174 by nerli@mozilla.com at Wed, 22 May 2019 03:46:05 +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 474654
Push 113165 by dvarga@mozilla.com at Tue, 21 May 2019 04:23:23 +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 474490
Push 113162 by rgurzau@mozilla.com at Mon, 20 May 2019 13:50:44 +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 474489
Push 113162 by rgurzau@mozilla.com at Mon, 20 May 2019 13:50:44 +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 474488
Push 113162 by rgurzau@mozilla.com at Mon, 20 May 2019 13:50:44 +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 474298
Push 113144 by shindli@mozilla.com at Fri, 17 May 2019 16:44:55 +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 474022
Push 113120 by dvarga@mozilla.com at Thu, 16 May 2019 04:21:05 +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 473182
Push 113068 by nerli@mozilla.com at Thu, 09 May 2019 15:38:15 +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 473173
Push 113068 by nerli@mozilla.com at Thu, 09 May 2019 15:38:15 +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 473172
Push 113068 by nerli@mozilla.com at Thu, 09 May 2019 15:38:15 +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 473171
Push 113068 by nerli@mozilla.com at Thu, 09 May 2019 15:38:15 +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 473169
Push 113068 by nerli@mozilla.com at Thu, 09 May 2019 15:38:15 +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 472797
Push 113048 by shindli@mozilla.com at Tue, 07 May 2019 09:56:38 +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 470325
Push 112863 by shindli@mozilla.com at Mon, 22 Apr 2019 09:53:25 +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 470275
Push 112851 by rgurzau@mozilla.com at Sat, 20 Apr 2019 10:03:47 +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 470201
Push 112847 by dluca@mozilla.com at Fri, 19 Apr 2019 21:51:54 +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 470034
Push 112839 by apavel@mozilla.com at Thu, 18 Apr 2019 21:50:57 +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 470033
Push 112839 by apavel@mozilla.com at Thu, 18 Apr 2019 21:50:57 +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 470032
Push 112839 by apavel@mozilla.com at Thu, 18 Apr 2019 21:50:57 +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 470031
Push 112839 by apavel@mozilla.com at Thu, 18 Apr 2019 21:50:57 +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 469352
Push 112787 by apavel@mozilla.com at Sat, 13 Apr 2019 21:53:37 +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 468939
Push 112762 by aciure@mozilla.com at Thu, 11 Apr 2019 09:57:48 +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 468923
Push 112762 by aciure@mozilla.com at Thu, 11 Apr 2019 09:57:48 +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 468627
Push 112738 by nbeleuzu@mozilla.com at Tue, 09 Apr 2019 22:28:41 +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 468469
Push 112724 by nerli@mozilla.com at Tue, 09 Apr 2019 10:03:26 +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 465480
Push 112510 by apavel@mozilla.com at Fri, 22 Mar 2019 10:06:40 +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 465157
Push 112493 by opoprus@mozilla.com at Wed, 20 Mar 2019 11:12:22 +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 464934
Push 112486 by opoprus@mozilla.com at Tue, 19 Mar 2019 16:41:04 +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 464933
Push 112486 by opoprus@mozilla.com at Tue, 19 Mar 2019 16:41:04 +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 464932
Push 112486 by opoprus@mozilla.com at Tue, 19 Mar 2019 16:41:04 +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 464931
Push 112486 by opoprus@mozilla.com at Tue, 19 Mar 2019 16:41:04 +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 464930
Push 112486 by opoprus@mozilla.com at Tue, 19 Mar 2019 16:41:04 +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 464929
Push 112486 by opoprus@mozilla.com at Tue, 19 Mar 2019 16:41:04 +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 464927
Push 112486 by opoprus@mozilla.com at Tue, 19 Mar 2019 16:41:04 +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 464926
Push 112486 by opoprus@mozilla.com at Tue, 19 Mar 2019 16:41:04 +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 464779
Push 112481 by rgurzau@mozilla.com at Mon, 18 Mar 2019 21:51:19 +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 464778
Push 112481 by rgurzau@mozilla.com at Mon, 18 Mar 2019 21:51:19 +0000
Bug 1518816 - Set the "may have transform animations" flag on the primary frame; r=hiro Differential Revision: https://phabricator.services.mozilla.com/D23635