searching for reviewer(hiro)
6a9a26055f9c47058638838305867c87e86eddec: Bug 1597273 - Handle logical shorthand animations with variable references correctly. r=hiro
Emilio Cobos Álvarez <emilio@crisal.io> - Tue, 19 Nov 2019 00:43:34 +0000 - rev 502520
Push 114172 by dluca@mozilla.com at Tue, 19 Nov 2019 11:31:10 +0000
Bug 1597273 - Handle logical shorthand animations with variable references correctly. r=hiro When we physicalize the declarations for @keyframes, we end up having a physical declaration with an unparsed value with `from_shorthand` being the logical shorthand. Account for this case properly when substituting custom properties, to avoid panicking. Differential Revision: https://phabricator.services.mozilla.com/D53663
7dc52ca0f1de82924ef9ac2b8d04e8852ed08ab1: Bug 1596610 - Set WillChangeBits::TRANSFORM for offset-path and add tests for it. r=hiro
Boris Chiou <boris.chiou@gmail.com> - Sat, 16 Nov 2019 01:52:32 +0000 - rev 502315
Push 114172 by dluca@mozilla.com at Tue, 19 Nov 2019 11:31:10 +0000
Bug 1596610 - Set WillChangeBits::TRANSFORM for offset-path and add tests for it. r=hiro Differential Revision: https://phabricator.services.mozilla.com/D53109
1a964a2674d330898518affd0f9de9520b46b1fa: Bug 1594960 - Update the assertion to check the transform-like animations on the compositor when we have fixed offset-path. r=hiro
Boris Chiou <boris.chiou@gmail.com> - Fri, 08 Nov 2019 23:46:17 +0000 - rev 501395
Push 114169 by ncsoregi@mozilla.com at Mon, 11 Nov 2019 12:39:11 +0000
Bug 1594960 - Update the assertion to check the transform-like animations on the compositor when we have fixed offset-path. r=hiro It's possible to have a fixed offset-path together with other animating css transform properties or offset-* properties, so we have to update this assertion. Differential Revision: https://phabricator.services.mozilla.com/D52296
102f2c8d892397d71b37027138ee8e764467e988: Bug 1592787 - No need to send non-animating offset-* if no effective motion path. r=hiro
Boris Chiou <boris.chiou@gmail.com> - Wed, 06 Nov 2019 20:17:10 +0000 - rev 500983
Push 114166 by apavel@mozilla.com at Thu, 07 Nov 2019 10:04:01 +0000
Bug 1592787 - No need to send non-animating offset-* if no effective motion path. r=hiro Differential Revision: https://phabricator.services.mozilla.com/D50012
3bfe8e0917c2e0d5c5987f246ffcce9715a30617: Bug 1592787 - Don't run compositor animations if offset-path is not animating and is none. r=hiro
Boris Chiou <boris.chiou@gmail.com> - Wed, 06 Nov 2019 20:17:07 +0000 - rev 500982
Push 114166 by apavel@mozilla.com at Thu, 07 Nov 2019 10:04:01 +0000
Bug 1592787 - Don't run compositor animations if offset-path is not animating and is none. r=hiro So, we don't create a stacking context for this case. Besides, we also make sure FindAnimationsForCompositor() work properly for motion-path if offset-path is not effective (i.e. none and no animations). Differential Revision: https://phabricator.services.mozilla.com/D51895
012c857ee2080f79c1140f7ed921726e7fe379b5: Bug 1429305 - Enable OMTA for motion path and add some tests for it. r=hiro
Boris Chiou <boris.chiou@gmail.com> - Thu, 31 Oct 2019 21:16:35 +0000 - rev 500105
Push 114164 by aiakab@mozilla.com at Tue, 05 Nov 2019 10:06:15 +0000
Bug 1429305 - Enable OMTA for motion path and add some tests for it. r=hiro Differential Revision: https://phabricator.services.mozilla.com/D50015
b0d2fc65047881e4eeb992ca671763dcd672c6c4: Bug 1429305 - Extend compositor properties for motion. r=hiro
Boris Chiou <boris.chiou@gmail.com> - Thu, 31 Oct 2019 20:07:45 +0000 - rev 500104
Push 114164 by aiakab@mozilla.com at Tue, 05 Nov 2019 10:06:15 +0000
Bug 1429305 - Extend compositor properties for motion. r=hiro Differential Revision: https://phabricator.services.mozilla.com/D50014
5159301a84467ac850fb17ccb817b5a977d5a59c: Bug 1429305 - Cache gfx path. r=hiro
Boris Chiou <boris.chiou@gmail.com> - Thu, 31 Oct 2019 21:36:39 +0000 - rev 500103
Push 114164 by aiakab@mozilla.com at Tue, 05 Nov 2019 10:06:15 +0000
Bug 1429305 - Cache gfx path. r=hiro We cache the path in AnimationInfo for layers, and in CompsoitorAnimationStorage for web-renderer. Differential Revision: https://phabricator.services.mozilla.com/D50013
0a68f6ee4e49926f3b3be0a3ac5096dc8f925144: Bug 1429305 - Add new layer messages for passing motion path info. r=hiro,mattwoodrow
Boris Chiou <boris.chiou@gmail.com> - Thu, 31 Oct 2019 20:07:41 +0000 - rev 500102
Push 114164 by aiakab@mozilla.com at Tue, 05 Nov 2019 10:06:15 +0000
Bug 1429305 - Add new layer messages for passing motion path info. r=hiro,mattwoodrow This also includes the implementation of SetAnimatable, FromAnimatable, and merge the final matrix with motion path. Besides, we always use PathBuilderSkia for calculating the gfx::Path for web-renderer. Differential Revision: https://phabricator.services.mozilla.com/D50011
a3d6aab91bd49278368fbc5f7adc8bf453c730da: Bug 1429305 - Make PathBuilder as a parameter. r=hiro
Boris Chiou <boris.chiou@gmail.com> - Thu, 31 Oct 2019 20:07:31 +0000 - rev 500100
Push 114164 by aiakab@mozilla.com at Tue, 05 Nov 2019 10:06:15 +0000
Bug 1429305 - Make PathBuilder as a parameter. r=hiro On the compositor thread in GPU process (i.e. web-renderer), gfxPlatform() is not initialized, so we don't have the DrawTarget information. Fortunately, all we need is to calculate the motion point and direction vector, so we don't have to care about which backend we use. Therefore, make PathBuilder as a parameter, so we can just pass a valid PathBuilder on the compositor thread. For main thread (i.e. content process), using the original way is fine. Differential Revision: https://phabricator.services.mozilla.com/D50010
6b0c544e7744862c29eb182f797e3f8c6b34c164: Bug 1429305 - Refactor for ResolveMotionPath. r=hiro
Boris Chiou <boris.chiou@gmail.com> - Thu, 31 Oct 2019 20:07:30 +0000 - rev 500099
Push 114164 by aiakab@mozilla.com at Tue, 05 Nov 2019 10:06:15 +0000
Bug 1429305 - Refactor for ResolveMotionPath. r=hiro The current implementation uses nsIFrame to get everything. However, we want to reuse ResolveMotionPath() on the compositor thread (in the parent process), so we need to refactor this function to avoid using nsIframe everywhere. Differential Revision: https://phabricator.services.mozilla.com/D50009
fc105e53c1cd98a4bfa0f17ee9e4707996198899: Bug 1429305 - Move motion path utils into a separate file. r=hiro
Boris Chiou <boris.chiou@gmail.com> - Thu, 31 Oct 2019 20:07:28 +0000 - rev 500098
Push 114164 by aiakab@mozilla.com at Tue, 05 Nov 2019 10:06:15 +0000
Bug 1429305 - Move motion path utils into a separate file. r=hiro I'd like to add some new data type for motion path, so it'd be great to put all of them in an independent file. Differential Revision: https://phabricator.services.mozilla.com/D50008
5dc1f98435bb24f9bfe8eeabf4a3c2070e85a32e: Bug 1591297 - Remove -moz-binding, nsStyleDisplay::mBinding and similar. r=hiro
Emilio Cobos Álvarez <emilio@crisal.io> - Sat, 26 Oct 2019 11:37:33 +0000 - rev 499596
Push 114161 by ncsoregi@mozilla.com at Tue, 29 Oct 2019 21:34:24 +0000
Bug 1591297 - Remove -moz-binding, nsStyleDisplay::mBinding and similar. r=hiro Differential Revision: https://phabricator.services.mozilla.com/D50556
4a880608ee123842c1e688f6c59a9f900c339055: Bug 1591297 - Remove some XBL code in the style system. r=hiro
Emilio Cobos Álvarez <emilio@crisal.io> - Fri, 25 Oct 2019 12:19:21 +0000 - rev 499594
Push 114161 by ncsoregi@mozilla.com at Tue, 29 Oct 2019 21:34:24 +0000
Bug 1591297 - Remove some XBL code in the style system. r=hiro Differential Revision: https://phabricator.services.mozilla.com/D50554
644d5c291870d25ac5b1f2f6c416c22042697dba: Bug 1590949 - Clean up no-longer-needed test metadata in interpolation-per-property.html.ini; r=hiro
Brian Birtles <birtles@gmail.com> - Thu, 24 Oct 2019 01:48:59 +0000 - rev 498796
Push 114159 by shindli@mozilla.com at Thu, 24 Oct 2019 09:49:00 +0000
Bug 1590949 - Clean up no-longer-needed test metadata in interpolation-per-property.html.ini; r=hiro Differential Revision: https://phabricator.services.mozilla.com/D50409
c09df0d0e60c7a9e3b2db185bae6aba42edadcfe: Bug 1588969 - Add --run-until-failure and --repeat options for |mach geckoview-junit|; r=bc,hiro
Geoff Brown <gbrown@mozilla.com> - Wed, 23 Oct 2019 22:45:49 +0000 - rev 498786
Push 114159 by shindli@mozilla.com at Thu, 24 Oct 2019 09:49:00 +0000
Bug 1588969 - Add --run-until-failure and --repeat options for |mach geckoview-junit|; r=bc,hiro Added a loop for repeating the requested test(s). With --run-until-failure, loop until a test fails. With --repeat=N, repeat N times. eg, --repeat=1 implies 2 runs total (same as mochitest). (Incidentally moved code for --enable-webrender since it was not in the appropriate section.) Differential Revision: https://phabricator.services.mozilla.com/D50299
f6fdb9788557adf48b9f69884a1bbd6b3b8214eb: Bug 1590278 - Cleanup scrollframe virtual / override / final declarations. r=hiro
Emilio Cobos Álvarez <emilio@crisal.io> - Tue, 22 Oct 2019 12:25:06 +0000 - rev 498543
Push 114159 by shindli@mozilla.com at Thu, 24 Oct 2019 09:49:00 +0000
Bug 1590278 - Cleanup scrollframe virtual / override / final declarations. r=hiro There's so much noise. Every time I read it I feel lost in a sea of virtual keywords :) This should help. Differential Revision: https://phabricator.services.mozilla.com/D50022
a8089b1fa5c4f678f64ae07102ee3863a63d8c31: Bug 1590281 - Don't propagate overscroll-behavior from body to viewport. r=hiro
Emilio Cobos Álvarez <emilio@crisal.io> - Tue, 22 Oct 2019 12:16:13 +0000 - rev 498542
Push 114159 by shindli@mozilla.com at Thu, 24 Oct 2019 09:49:00 +0000
Bug 1590281 - Don't propagate overscroll-behavior from body to viewport. r=hiro Differential Revision: https://phabricator.services.mozilla.com/D50024
c4c8d268fb0e2a5c533d8b82b71ef0ccac9f2fdb: Bug 1590273 - Remove useless early-outs in nsStyle{Padding,Margin}::CalcDifference. r=hiro
Emilio Cobos Álvarez <emilio@crisal.io> - Tue, 22 Oct 2019 02:34:20 +0000 - rev 498466
Push 114158 by ncsoregi@mozilla.com at Tue, 22 Oct 2019 09:53:30 +0000
Bug 1590273 - Remove useless early-outs in nsStyle{Padding,Margin}::CalcDifference. r=hiro Best-case they're redundant. Differential Revision: https://phabricator.services.mozilla.com/D50021
9ca90d25365c88f4afdba98a9feb8160465b12b6: Bug 1588792 - Enable the pref of individual transforms for will-change wpt in vendor-imports. r=hiro
Boris Chiou <boris.chiou@gmail.com> - Thu, 17 Oct 2019 22:46:34 +0000 - rev 498108
Push 114157 by nbeleuzu@mozilla.com at Mon, 21 Oct 2019 22:00:13 +0000
Bug 1588792 - Enable the pref of individual transforms for will-change wpt in vendor-imports. r=hiro Differential Revision: https://phabricator.services.mozilla.com/D49334
f55f6ce5cc90d28156a9340dd26769b00ac25db9: Bug 1588743 - Remove old scroll-snap implementation, and scroll snapping prefs. r=hiro
Emilio Cobos Álvarez <emilio@crisal.io> - Tue, 15 Oct 2019 12:40:14 +0000 - rev 497629
Push 114154 by btara@mozilla.com at Thu, 17 Oct 2019 09:58:40 +0000
Bug 1588743 - Remove old scroll-snap implementation, and scroll snapping prefs. r=hiro Differential Revision: https://phabricator.services.mozilla.com/D49267
1a951477dca5c62745b35a26b7c9226b833c6345: Bug 1588743 - Remove old scroll-snap implementation, and scroll snapping prefs. r=hiro
Emilio Cobos Álvarez <emilio@crisal.io> - Tue, 15 Oct 2019 11:39:30 +0000 - rev 497621
Push 114154 by btara@mozilla.com at Thu, 17 Oct 2019 09:58:40 +0000
Bug 1588743 - Remove old scroll-snap implementation, and scroll snapping prefs. r=hiro Differential Revision: https://phabricator.services.mozilla.com/D49267
a1dfda2720234ceff5e27a8a9548201aec1e2c94: Bug 1586600 - Make nsPresContext's overflow propagation match the spec. r=hiro
Emilio Cobos Álvarez <emilio@crisal.io> - Tue, 15 Oct 2019 10:33:14 +0000 - rev 497613
Push 114154 by btara@mozilla.com at Thu, 17 Oct 2019 09:58:40 +0000
Bug 1586600 - Make nsPresContext's overflow propagation match the spec. r=hiro From https://drafts.csswg.org/css-overflow/#overflow-propagation: > UAs must apply the overflow-* values set on the root element to the viewport. > However, when the root element is an [HTML] html element (including XML syntax > for HTML) whose overflow value is visible (in both axes), and that element has > a body element as a child, user agents must instead apply the overflow-* > values of the first such child element to the viewport. The element from which > the value is propagated must then have a used overflow value of visible. This was out of sync with Document::IsScrollingElement, which implements the right thing. Differential Revision: https://phabricator.services.mozilla.com/D49196
2947c5ae2f8b847fe366d54baf608a057b6d34ad: Bug 1586600 - Make nsPresContext's overflow propagation match the spec. r=hiro
Emilio Cobos Álvarez <emilio@crisal.io> - Mon, 14 Oct 2019 22:29:17 +0000 - rev 497553
Push 114152 by dvarga@mozilla.com at Tue, 15 Oct 2019 11:14:34 +0000
Bug 1586600 - Make nsPresContext's overflow propagation match the spec. r=hiro From https://drafts.csswg.org/css-overflow/#overflow-propagation: > UAs must apply the overflow-* values set on the root element to the viewport. > However, when the root element is an [HTML] html element (including XML syntax > for HTML) whose overflow value is visible (in both axes), and that element has > a body element as a child, user agents must instead apply the overflow-* > values of the first such child element to the viewport. The element from which > the value is propagated must then have a used overflow value of visible. This was out of sync with Document::IsScrollingElement, which implements the right thing. Differential Revision: https://phabricator.services.mozilla.com/D49196
bb30c0d750556c4db5163efe7f00c3067b1d955c: Bug 1506939 - Enable individual transform on nightly. r=hiro
Boris Chiou <boris.chiou@gmail.com> - Mon, 07 Oct 2019 21:48:44 +0000 - rev 496693
Push 114145 by apavel@mozilla.com at Tue, 08 Oct 2019 11:00:56 +0000
Bug 1506939 - Enable individual transform on nightly. r=hiro Differential Revision: https://phabricator.services.mozilla.com/D48239
40de8675c53c4593ae201c261406a79a5e8c0adb: Bug 1510486 - Add reftests for creating stacking-context and fixpos containing block on individual transforms. r=hiro
Boris Chiou <boris.chiou@gmail.com> - Mon, 30 Sep 2019 21:52:32 +0000 - rev 495760
Push 114140 by dvarga@mozilla.com at Wed, 02 Oct 2019 18:04:51 +0000
Bug 1510486 - Add reftests for creating stacking-context and fixpos containing block on individual transforms. r=hiro To make sure the test coverage is enough for individual transforms. Differential Revision: https://phabricator.services.mozilla.com/D47515
83d5c614484033e41dfbf35f3f05f01836aa405f: Bug 1510486 - Set WillChangeBits::TRANSFORM for individual transform. r=hiro
Boris Chiou <boris.chiou@gmail.com> - Mon, 30 Sep 2019 21:52:30 +0000 - rev 495759
Push 114140 by dvarga@mozilla.com at Wed, 02 Oct 2019 18:04:51 +0000
Bug 1510486 - Set WillChangeBits::TRANSFORM for individual transform. r=hiro We always check StyleWillChangeBits_TRANSFORM bit together with a transform-like property set, so using WillChangeBits::TRANSFORM bit to represent all transform-like properties is ok. However, it seems the new test case works well even if we don't have this patch. I still add it for individual transform properties to make sure the test coverage is enough anyway. Differential Revision: https://phabricator.services.mozilla.com/D47509
ecbb08dbe3bab1fecb5158b33c6b6dc3bbe3e69e: Bug 1582775 - disabled browser_deck_has_out_of_process_iframe.js on win qr r=hiro
Andreea Pavel <apavel@mozilla.com> - Thu, 26 Sep 2019 03:47:47 +0000 - rev 495040
Push 114131 by dluca@mozilla.com at Thu, 26 Sep 2019 09:47:34 +0000
Bug 1582775 - disabled browser_deck_has_out_of_process_iframe.js on win qr r=hiro Differential Revision: https://phabricator.services.mozilla.com/D47188
ab74e2147c5c1761ac324bbdf993d6aa0891ca96: Bug 1551659 - Remove MVMContext::ResizeEventFlag and related code. r=botond,hiro
Emilio Cobos Álvarez <emilio@crisal.io> - Wed, 25 Sep 2019 19:35:29 +0000 - rev 494971
Push 114131 by dluca@mozilla.com at Thu, 26 Sep 2019 09:47:34 +0000
Bug 1551659 - Remove MVMContext::ResizeEventFlag and related code. r=botond,hiro D46944 / bug 1583534 is what fixes the root cause of bug 1528052 by not having the first call to ResizeReflow have a wrong old size of 0x0. This removes the code that bug introduces to suppress resize events, which fixes this bug. I think our behavior now is pretty sane. In particular, consider the test-case: <!doctype html> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <a href="" target="_blank">Open me in a separate tab</a> <pre id="log"></pre> <script> // This shouldn't be needed, but otherwise Fenix doesn't show the tooltip on // longpress... document.querySelector("a").href = location.href; function logSize() { log.innerText += window.innerWidth + "x" + window.innerHeight + "\n"; } logSize(); onresize = logSize; </script> (Hosted at https://crisal.io/tmp/gecko-mobile-resize.html for convenience) Right now on trunk, when you click the link from GVE or Fenix, we're only getting an initial size of 0x0 (which is not great, btw), and only after first paint we get the real device size, but content doesn't get a resize event. This is obviously wrong, every time the layout viewport changes we should fire resize events. Pages that get opened in new tabs and get refreshed when resized may get an extra reload with this approach, but this seems not avoidable unless widget sets the viewport size right in advance (which from discussion with snorp and agi doesn't seem possible in the general case). What used to happen is that we were triggering a redundant resize reflow from the initial paint which didn't update the layout viewport (because the content viewer and co had the right viewport from the previous navigation). Now that we optimize those away, I think our behavior should be correct. Differential Revision: https://phabricator.services.mozilla.com/D46956
2a39731bf265d0340924be02ade31b9d2ddfff8f: Bug 1583483 - Add the pref of implicit keyframes for css-ui animations. r=hiro
Boris Chiou <boris.chiou@gmail.com> - Tue, 24 Sep 2019 22:40:20 +0000 - rev 494845
Push 114131 by dluca@mozilla.com at Thu, 26 Sep 2019 09:47:34 +0000
Bug 1583483 - Add the pref of implicit keyframes for css-ui animations. r=hiro The test uses implicit keyframes, so need to add this preference. Differential Revision: https://phabricator.services.mozilla.com/D47012
73d9659e771568620eabb8e23276a0e62b5c0b4d: Bug 1578125 - Fix flakiness in common animation interpolation testing functions; r=hiro
Brian Birtles <birtles@gmail.com> - Sat, 21 Sep 2019 11:57:14 +0000 - rev 494413
Push 114117 by shindli@mozilla.com at Sat, 21 Sep 2019 21:52:18 +0000
Bug 1578125 - Fix flakiness in common animation interpolation testing functions; r=hiro This patch fixes a number of issues with the common interpolation testing functions upstreamed from Blink. Firstly this test file sets an animation duration of 2,000,000,000s and a delay of -1,000,000,000s but that does not appear to be necessary since no time elapses between when the animation is established and when the result is checked (measure() is called immediately after interpolate() without any interleaving call to requestAnimationFrame, for example). Furthermore, this long time will cause some configurations of Firefox on Windows to treat the time as an infinite time and end up producing discrete animation. There is nothing in CSS values that requires supporting times of this magnitude (~63 years) so it seems best not to make the tests rely on it being supported (the tests are intended to cover interpolation after all, not timing range) and instead to use a shorter time. Similarly, for the Web Animations interpolation tests, this utility function uses a duration of 1ms and seeks to 0.5ms. This can likewise lead to precision issues, particularly when testing interpolation pairs that fall back to discrete animation since in that case, the test will seek to precisely 0.5ms and test that the result is at the top of the step that occurs at that time. Floating-point error can cause this to fail so this patch changes the duration and seek time to 100s and 50s respectively. This patch also includes a few additional tweaks to this file including: * Replacing the "steps(2, end)" timing function with "linear" since this avoids floating-point errors at the 0.5 mark. * Adding translation for "float" to "cssFloat". * Triggering transitions by querying the property being transitioned. (In theory a UA could skip flushing all styles when accessing the 'left' property but in practice that is probably not Web-compatible.) Differential Revision: https://phabricator.services.mozilla.com/D46698
0626a86d78b12627264c0d279892e9ff0f98f42a: Bug 1578125 - Fix flakiness in common animation interpolation testing functions; r=hiro
Brian Birtles <birtles@gmail.com> - Sat, 21 Sep 2019 06:19:20 +0000 - rev 494393
Push 114115 by aiakab@mozilla.com at Sat, 21 Sep 2019 10:09:09 +0000
Bug 1578125 - Fix flakiness in common animation interpolation testing functions; r=hiro This patch fixes a number of issues with the common interpolation testing functions upstreamed from Blink. Firstly this test file sets an animation duration of 2,000,000,000s and a delay of -1,000,000,000s but that does not appear to be necessary since no time elapses between when the animation is established and when the result is checked (measure() is called immediately after interpolate() without any interleaving call to requestAnimationFrame, for example). Furthermore, this long time will cause some configurations of Firefox on Windows to treat the time as an infinite time and end up producing discrete animation. There is nothing in CSS values that requires supporting times of this magnitude (~63 years) so it seems best not to make the tests rely on it being supported (the tests are intended to cover interpolation after all, not timing range) and instead to use a shorter time. Similarly, for the Web Animations interpolation tests, this utility function uses a duration of 1ms and seeks to 0.5ms. This can likewise lead to precision issues, particularly when testing interpolation pairs that fall back to discrete animation since in that case, the test will seek to precisely 0.5ms and test that the result is at the top of the step that occurs at that time. Floating-point error can cause this to fail so this patch changes the duration and seek time to 100s and 50s respectively. This patch also includes a few additional tweaks to this file including: * Replacing the "steps(2, end)" timing function with "linear" since this avoids floating-point errors at the 0.5 mark. * Adding translation for "float" to "cssFloat". * Triggering transitions by querying the property being transitioned. (In theory a UA could skip flushing all styles when accessing the 'left' property but in practice that is probably not Web-compatible.) Differential Revision: https://phabricator.services.mozilla.com/D46698
e452ba381a62a156b5dd9b291b5f57ea01afc756: Bug 1561546 Part 1 - Change scrollbar pref early. r=hiro
Adam Gashlin <agashlin@mozilla.com> - Wed, 18 Sep 2019 21:28:06 +0000 - rev 494143
Push 114108 by dvarga@mozilla.com at Fri, 20 Sep 2019 09:59:36 +0000
Bug 1561546 Part 1 - Change scrollbar pref early. r=hiro Differential Revision: https://phabricator.services.mozilla.com/D46363
9dcc8e550559887b04d810e828eebc6a2ab2027d: Bug 1577236 - clang-10: Fix -Wimplicit-int-float-conversion warnings in dom/animation/ r=hiro
Sylvestre Ledru <sledru@mozilla.com> - Wed, 28 Aug 2019 21:31:46 +0000 - rev 490507
Push 113995 by ccoroiu@mozilla.com at Thu, 29 Aug 2019 04:13:32 +0000
Bug 1577236 - clang-10: Fix -Wimplicit-int-float-conversion warnings in dom/animation/ r=hiro Depends on D43779 Differential Revision: https://phabricator.services.mozilla.com/D43780
5885e492eaaf4fdb288ad832866848e5987a22b5: Bug 1575926 - Check that we have a target in CalculateCumulativeChangeHint. r=hiro
Emilio Cobos Álvarez <emilio@crisal.io> - Mon, 26 Aug 2019 09:08:22 +0000 - rev 489847
Push 113976 by malexandru@mozilla.com at Mon, 26 Aug 2019 23:07:04 +0000
Bug 1575926 - Check that we have a target in CalculateCumulativeChangeHint. r=hiro Seems we'll update the change hint properly via SetTarget if we get a new target. Differential Revision: https://phabricator.services.mozilla.com/D43397
fa0fc354ee09a6a027229b5c0c9f26efc808fd35: Bug 1573014 - Early-exit ShrinkToDisplaySizeIfNeeded() in reader mode. r=hiro
Botond Ballo <botond@mozilla.com> - Wed, 21 Aug 2019 23:33:14 +0000 - rev 489319
Push 113942 by aciure@mozilla.com at Thu, 22 Aug 2019 04:06:52 +0000
Bug 1573014 - Early-exit ShrinkToDisplaySizeIfNeeded() in reader mode. r=hiro Differential Revision: https://phabricator.services.mozilla.com/D42967
981d686b81d2658ccdb1e3997bbf0c8314a445d5: Bug 1575093 - Ensure initial-scale in a meta viewport tag is respected. r=hiro
Botond Ballo <botond@mozilla.com> - Wed, 21 Aug 2019 22:00:43 +0000 - rev 489293
Push 113942 by aciure@mozilla.com at Thu, 22 Aug 2019 04:06:52 +0000
Bug 1575093 - Ensure initial-scale in a meta viewport tag is respected. r=hiro Differential Revision: https://phabricator.services.mozilla.com/D42949
e7e658ec1e98c3868b98195c2ee4b9fe3842172e: Bug 1574957 - Clamp negative values for font-size-adjust animations. r=hiro
Boris Chiou <boris.chiou@gmail.com> - Tue, 20 Aug 2019 01:30:43 +0000 - rev 488887
Push 113927 by cbrindusan@mozilla.com at Tue, 20 Aug 2019 09:45:16 +0000
Bug 1574957 - Clamp negative values for font-size-adjust animations. r=hiro Differential Revision: https://phabricator.services.mozilla.com/D42586
c2b9e7cc9c9f498b7a0b42c327f04040a743dfae: Bug 1574921 - Enable the pref for compositing animation in css/css-transforms. r=hiro
Boris Chiou <boris.chiou@gmail.com> - Mon, 19 Aug 2019 20:53:27 +0000 - rev 488813
Push 113926 by ccoroiu@mozilla.com at Tue, 20 Aug 2019 03:58:58 +0000
Bug 1574921 - Enable the pref for compositing animation in css/css-transforms. r=hiro Differential Revision: https://phabricator.services.mozilla.com/D42553
4d29e1e9ed0880dbc450bd04d4a462a6380edbc1: Bug 1571211 - Enable the pref of motion path in dom/animation/test/chrome. r=hiro
Boris Chiou <boris.chiou@gmail.com> - Tue, 06 Aug 2019 23:51:54 +0000 - rev 486639
Push 113849 by aciure@mozilla.com at Wed, 07 Aug 2019 04:39:23 +0000
Bug 1571211 - Enable the pref of motion path in dom/animation/test/chrome. r=hiro Differential Revision: https://phabricator.services.mozilla.com/D40570
cca6fafe48dd35142d2446de4cb1247d9704d63b: Bug 1570726 Part 2 - Don't call UpdateVisibleDescendantsState() when creating a continuation. r=hiro
Ting-Yu Lin <tlin@mozilla.com> - Fri, 02 Aug 2019 22:16:11 +0000 - rev 486061
Push 113827 by btara@mozilla.com at Sat, 03 Aug 2019 09:54:50 +0000
Bug 1570726 Part 2 - Don't call UpdateVisibleDescendantsState() when creating a continuation. r=hiro After moving the logic that carries NS_FRAME_OUT_OF_FLOW bit from the prev-in-flow into nsFrame::Init() in Part 1, testing/web-platform/tests/css/css-multicol/float-and-block.html starts to crash. In the test, it has a float element that fragments into two columns. When creating a continuation for the float frame, we have a callstack looks like nsFrame::Init() -> UpdateVisibleDescendantsState() -> GetInFlowParent(). Because NS_FRAME_OUT_OF_FLOW is set in nsFrame::Init(), GetInFlowParent() tries to get PlaceholderFrameProperty() on its FirstContinuation(), but the first continuation is not established until the end of nsCSSFrameConstructor::CreateContinuingFrame(). This being said, we don't need to UpdateVisibleDescendantsState() when creating continuations because UpdateVisibleDescendantsState() needs to traverse a stable frame tree, and the animation code only looks at the primary frames. Differential Revision: https://phabricator.services.mozilla.com/D40245
da1b2c17a9e5f3a723a0713aeeb4d0c71133bcc2: Bug 1569795 - Block compositor animations of transform-like properties if offset-path is not none. r=hiro
Boris Chiou <boris.chiou@gmail.com> - Thu, 01 Aug 2019 21:22:49 +0000 - rev 485989
Push 113825 by opoprus@mozilla.com at Fri, 02 Aug 2019 22:01:10 +0000
Bug 1569795 - Block compositor animations of transform-like properties if offset-path is not none. r=hiro The animations of motion path are not running on the compositor, and the properties in [motion-1] is not part of transform-like properties (i.e. nsCSSProperties::TransformLikeProperties()) for now, so we should run transform animations on the main thread if offset-path is not `none`. Differential Revision: https://phabricator.services.mozilla.com/D39966
e73d900b1dcf01da7c7023d7d6ee70043be5d9cf: Bug 1387894, 1476950 - Fix test_restyles.html for unconditional clamping. r=birtles,hiro
Tom Ritter <tom@mozilla.com> - Fri, 02 Aug 2019 07:36:19 +0200 - rev 485914
Push 113824 by csabou@mozilla.com at Fri, 02 Aug 2019 16:06:39 +0000
Bug 1387894, 1476950 - Fix test_restyles.html for unconditional clamping. r=birtles,hiro This refactors things to run until the animation is unthrottled. It confirms the proper amount of time has passed; and then awaits another styling to ensure that markers.length = 0 (unless it took very long (over 200ms) that it should be 1. Differential Revision: https://phabricator.services.mozilla.com/D38808 Depends on D38807
4a75f2556242a972fd49c0ef447df7f26de7344e: Bug 1387894, 1476950 - Fix test_restyles.html for unconditional clamping r=birtles,hiro
Tom Ritter <tom@mozilla.com> - Tue, 30 Jul 2019 15:11:59 +0000 - rev 485348
Push 113803 by dvarga@mozilla.com at Wed, 31 Jul 2019 00:31:34 +0000
Bug 1387894, 1476950 - Fix test_restyles.html for unconditional clamping r=birtles,hiro This refactors things to run until the animation is unthrottled. It confirms the proper amount of time has passed; and then awaits another styling to ensure that markers.length = 0 (unless it took very long (over 200ms) that it should be 1. Differential Revision: https://phabricator.services.mozilla.com/D38808
d1f09b772baca9dad66477f785bb606a7e83c1bd: Bug 1387894, 1476950 - Fix test_restyles.html for unconditional clamping r=birtles,hiro
Tom Ritter <tom@mozilla.com> - Tue, 30 Jul 2019 13:19:05 +0000 - rev 485311
Push 113803 by dvarga@mozilla.com at Wed, 31 Jul 2019 00:31:34 +0000
Bug 1387894, 1476950 - Fix test_restyles.html for unconditional clamping r=birtles,hiro This refactors things to run until the animation is unthrottled. It confirms the proper amount of time has passed; and then awaits another styling to ensure that markers.length = 0 (unless it took very long (over 200ms) that it should be 1. Differential Revision: https://phabricator.services.mozilla.com/D38808
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