searching for reviewer(kats)
bf72f2e5024ba404c624e3aedbaa11d445a81202: Bug 1658225. Ensure that WidgetWheelEvents produced from PinchGestureInputs always have a non-zero deltaY. r=kats
Timothy Nikkel <tnikkel@gmail.com> - Mon, 10 Aug 2020 13:21:45 +0000 - rev 544506
Push 124077 by tnikkel@mozilla.com at Thu, 13 Aug 2020 09:37:02 +0000
Bug 1658225. Ensure that WidgetWheelEvents produced from PinchGestureInputs always have a non-zero deltaY. r=kats See bug 1648489 for why we need this. If we don't send a pinch we don't want to update the last scale so that when we do send an event it incorporates the full scale change from the last time we sent an event. Even if aScale != mLastScale in SendPinch the computed deltaY ( = 100 * (aScale-mLastScale) * widgetscale) can be 0 seemingly because of floating point weirdness I guess. Depends on D86495 Differential Revision: https://phabricator.services.mozilla.com/D86496
bd9655461cbce5a309ba79ec6ab5cb71855356b2: Bug 1658001. Populate wheelEvent.mLineOrPageDeltaY in PinchGestureInput::ToWidgetWheel for pinch gestures produced from direct manipulation. r=kats
Timothy Nikkel <tnikkel@gmail.com> - Tue, 11 Aug 2020 09:08:06 +0000 - rev 544365
Push 123992 by tnikkel@mozilla.com at Wed, 12 Aug 2020 07:00:48 +0000
Bug 1658001. Populate wheelEvent.mLineOrPageDeltaY in PinchGestureInput::ToWidgetWheel for pinch gestures produced from direct manipulation. r=kats We do this analogously to how PanGestureInput does it except that the delta's that we compute mLineOrPageDeltaY from are computed by us instead of provided to us. mLineOrPageDeltaY being non-zero is what EventStateManager::DispatchLegacyMouseScrollEvents uses to decide to send legacy mouse events, so we need to populate it to get those legacy events to send. This fix is Windows only on purpose as pinches on macOS don't seem to send wheel events (Windows sends ctrl+wheel). When Linux gets implemented it will need to be determined what to do. Differential Revision: https://phabricator.services.mozilla.com/D86495
908278038cbc17d0679ac403707ca3174ea35ac3: Bug 1658647. Put the current keyboard modifiers on direct manipulation input events. r=kats
Timothy Nikkel <tnikkel@gmail.com> - Tue, 11 Aug 2020 23:30:57 +0000 - rev 544336
Push 123975 by tnikkel@mozilla.com at Tue, 11 Aug 2020 23:39:08 +0000
Bug 1658647. Put the current keyboard modifiers on direct manipulation input events. r=kats Differential Revision: https://phabricator.services.mozilla.com/D86779
f2f72d4877cc4346e4c4749baceba46c7e87278c: Bug 1658168. Make SmoothScrollAnimation pass float CSS pixels to AxisPhysicsMSDModel instead of app units. r=kats
Timothy Nikkel <tnikkel@gmail.com> - Mon, 10 Aug 2020 21:57:46 +0000 - rev 544220
Push 123899 by tnikkel@mozilla.com at Tue, 11 Aug 2020 03:21:39 +0000
Bug 1658168. Make SmoothScrollAnimation pass float CSS pixels to AxisPhysicsMSDModel instead of app units. r=kats This avoids a problem where apz side smooth scroll animations end immediately because the inaccuracy of converting to (integer) app units and back wrongly tells us that we have overscroll the non-moving axis if that axis is at the end of its range. When we do a smooth scroll animation on the apzc side we use AxisPhysicsMSDModel. AxisPhysicsMSDModel is also used on the main thread to do smooth scroll animations. AxisPhysicsMSDModel uses doubles to represent all coordinates. On the main thread we pass in appunits, so the output of AxisPhysicsMSDModel is also in appunits. On the apzc side we follow that to. A problem comes up when we do a smooth scroll animation in one axis, and the other axis is at the end of its range (and not animating). In the non-moving axis we convert the current scroll position (on the frame metrics) to appunits and pass it into AxisPhysicsMSDModel. Then when it comes time to call DoSample for the first time we ask for the position from AxisPhysicsMSDModel (in appunits) and then convert it to CSSPoint. And then we compare it with the current scroll position (on the frame metrics). Especially when we have zoom, the inaccuracy of this computation is enough for the difference between the CSSPoint for the current position from AxisPhysicsMSDModel and the current scroll offset (on the frame metrics) to be bigger than the epsilon that we use here: https://searchfox.org/mozilla-central/rev/491612fa0be0f809069ea62c6316bf452cacc816/gfx/layers/apz/src/AsyncPanZoomController.cpp#747 and we determine that we have overscrolled the non-moving axis, and therefore the animation must be over. Since AxisPhysicsMSDModel already operates purely on doubles if we just avoid converting to (integer) app units we avoid this problem. We could have AxisPhysicsMSDModel operate on float appunits, but that's a little inelegant because there aren't functions for converting to float appunits. We could also just have AxisPhysicsMSDModel operate on CSS pixels. That assumes that the physics calculations of AxisPhysicsMSDModel are scale independent, which I don't know for sure but they seem to be visually the same with CSS pixels. Differential Revision: https://phabricator.services.mozilla.com/D86481
96bfe4270ecbb29d0cf455cd473f034304fa6f3d: Bug 1658167. Use AsyncPanZoomController::GetCurrentAnimationDestination in one more place. r=kats
Timothy Nikkel <tnikkel@gmail.com> - Sun, 09 Aug 2020 21:06:27 +0000 - rev 544046
Push 123777 by tnikkel@mozilla.com at Sun, 09 Aug 2020 21:08:58 +0000
Bug 1658167. Use AsyncPanZoomController::GetCurrentAnimationDestination in one more place. r=kats Differential Revision: https://phabricator.services.mozilla.com/D86480
7b93758ae83e7a9cef0102849a56f9244d873afa: Bug 1656802. Make visual viewport only layout scrollbars affect the composition bounds/visual viewport. r=emilio,kats
Timothy Nikkel <tnikkel@gmail.com> - Fri, 07 Aug 2020 11:40:52 +0000 - rev 544019
Push 123757 by tnikkel@mozilla.com at Sat, 08 Aug 2020 07:11:47 +0000
Bug 1656802. Make visual viewport only layout scrollbars affect the composition bounds/visual viewport. r=emilio,kats AFAICT the spec says that these layout scrollbars that take up no layout space that scroll the visual viewport do affect the size of the visual viewport. (Double check this) Most other users don't care about the size of these special scrollbars. I left nsIDOMWindowUtils::getScrollbarSize unchanged (NB different from nsIDOMWindowUtils::getScrollbarSizes which is modified by this patch) because I'm less sure. I will file a followup about it. Differential Revision: https://phabricator.services.mozilla.com/D85708
0305c832b34ca1b458fc0555d7bc3d0ac3062cf6: Bug 1656802. Add state variables to the scroll frame to track when scrollbars are only created to scroll the visual viewport within the layout viewport. r=emilio,kats
Timothy Nikkel <tnikkel@gmail.com> - Fri, 07 Aug 2020 11:40:47 +0000 - rev 544013
Push 123757 by tnikkel@mozilla.com at Sat, 08 Aug 2020 07:11:47 +0000
Bug 1656802. Add state variables to the scroll frame to track when scrollbars are only created to scroll the visual viewport within the layout viewport. r=emilio,kats We need to distinguish these special scrollbars for several different reasons in upcoming patches. Differential Revision: https://phabricator.services.mozilla.com/D85702
72f6b67a2b9b88fb64e28717edd12d089fc76107: Bug 1656802. Calculate if we need scrollbars to scroll the visual viewport. r=emilio,kats
Timothy Nikkel <tnikkel@gmail.com> - Fri, 07 Aug 2020 11:40:46 +0000 - rev 544012
Push 123757 by tnikkel@mozilla.com at Sat, 08 Aug 2020 07:11:47 +0000
Bug 1656802. Calculate if we need scrollbars to scroll the visual viewport. r=emilio,kats This fixes the regression we created with the first patch. Differential Revision: https://phabricator.services.mozilla.com/D85701
169cb537921e3934d99d655e7ad9f259b5a2841c: Bug 1656802. When deciding if we want a scrollbar we need to consider only if the scrolled rect overflows the scrollport (not the visual viewport). r=emilio,kats
Timothy Nikkel <tnikkel@gmail.com> - Fri, 07 Aug 2020 11:40:50 +0000 - rev 544010
Push 123757 by tnikkel@mozilla.com at Sat, 08 Aug 2020 07:11:47 +0000
Bug 1656802. When deciding if we want a scrollbar we need to consider only if the scrolled rect overflows the scrollport (not the visual viewport). r=emilio,kats This will actually regress behaviour when overflow is auto and pinch zooming creates scrollable overflow (scrolling the visual viewport inside the layout viewport). We will fix that in later patches. The reason that this is necessary is that the code as-is is incorrect if we have layout scrollbars (scrollbars that take up space). If we have layout scrollbars and we pinch zoom and we go from not needing a scrollbar to needing a scrollbar then that scrollbar cannot take up layout space (even though it is a layout scrollbar). The scrollbar cannot change the size of the layout viewport (it does, however, change the size of the visual viewport). In later patches we fix this situation as well as the situation with an overflow hidden document (which also needs to create scrollbars when pinch zoomed). Differential Revision: https://phabricator.services.mozilla.com/D85699
941ee8aa9735811ea7ee35f365dc2aa5489bb8bd: Bug 1656802. Make visual viewport only layout scrollbars affect the composition bounds/visual viewport. r=emilio,kats
Timothy Nikkel <tnikkel@gmail.com> - Fri, 07 Aug 2020 10:05:10 +0000 - rev 543753
Push 123649 by tnikkel@mozilla.com at Fri, 07 Aug 2020 10:14:04 +0000
Bug 1656802. Make visual viewport only layout scrollbars affect the composition bounds/visual viewport. r=emilio,kats AFAICT the spec says that these layout scrollbars that take up no layout space that scroll the visual viewport do affect the size of the visual viewport. (Double check this) Most other users don't care about the size of these special scrollbars. I left nsIDOMWindowUtils::getScrollbarSize unchanged (NB different from nsIDOMWindowUtils::getScrollbarSizes which is modified by this patch) because I'm less sure. I will file a followup about it. Differential Revision: https://phabricator.services.mozilla.com/D85708
3865541100087eb7961933a9b34149858f2a9084: Bug 1656802. Add state variables to the scroll frame to track when scrollbars are only created to scroll the visual viewport within the layout viewport. r=emilio,kats
Timothy Nikkel <tnikkel@gmail.com> - Fri, 07 Aug 2020 10:03:33 +0000 - rev 543747
Push 123649 by tnikkel@mozilla.com at Fri, 07 Aug 2020 10:14:04 +0000
Bug 1656802. Add state variables to the scroll frame to track when scrollbars are only created to scroll the visual viewport within the layout viewport. r=emilio,kats We need to distinguish these special scrollbars for several different reasons in upcoming patches. Differential Revision: https://phabricator.services.mozilla.com/D85702
2d3576ace2f13706460b8ca0df99a429a064cca2: Bug 1656802. Calculate if we need scrollbars to scroll the visual viewport. r=emilio,kats
Timothy Nikkel <tnikkel@gmail.com> - Fri, 07 Aug 2020 10:03:26 +0000 - rev 543746
Push 123649 by tnikkel@mozilla.com at Fri, 07 Aug 2020 10:14:04 +0000
Bug 1656802. Calculate if we need scrollbars to scroll the visual viewport. r=emilio,kats This fixes the regression we created with the first patch. Differential Revision: https://phabricator.services.mozilla.com/D85701
57fa485424355e535c7eef7a13f2edc62a8b8351: Bug 1656802. When deciding if we want a scrollbar we need to consider only if the scrolled rect overflows the scrollport (not the visual viewport). r=emilio,kats
Timothy Nikkel <tnikkel@gmail.com> - Fri, 07 Aug 2020 10:06:14 +0000 - rev 543744
Push 123649 by tnikkel@mozilla.com at Fri, 07 Aug 2020 10:14:04 +0000
Bug 1656802. When deciding if we want a scrollbar we need to consider only if the scrolled rect overflows the scrollport (not the visual viewport). r=emilio,kats This will actually regress behaviour when overflow is auto and pinch zooming creates scrollable overflow (scrolling the visual viewport inside the layout viewport). We will fix that in later patches. The reason that this is necessary is that the code as-is is incorrect if we have layout scrollbars (scrollbars that take up space). If we have layout scrollbars and we pinch zoom and we go from not needing a scrollbar to needing a scrollbar then that scrollbar cannot take up layout space (even though it is a layout scrollbar). The scrollbar cannot change the size of the layout viewport (it does, however, change the size of the visual viewport). In later patches we fix this situation as well as the situation with an overflow hidden document (which also needs to create scrollbars when pinch zoomed). Differential Revision: https://phabricator.services.mozilla.com/D85699
b30f67f3e89cd26fc14c32f74f065a14ded0671b: Bug 1657482 - Modernize some loops. r=kats
Botond Ballo <botond@mozilla.com> - Thu, 06 Aug 2020 00:23:26 +0000 - rev 543520
Push 123509 by bballo@mozilla.com at Thu, 06 Aug 2020 01:23:38 +0000
Bug 1657482 - Modernize some loops. r=kats Use some structured binding goodness while we're at it. Depends on D86083 Differential Revision: https://phabricator.services.mozilla.com/D86084
735170c72536f7122bac5b686cf91605385a2afd: Bug 1657482 - Avoid unnecessary map lookups. r=kats
Botond Ballo <botond@mozilla.com> - Thu, 06 Aug 2020 00:22:33 +0000 - rev 543519
Push 123509 by bballo@mozilla.com at Thu, 06 Aug 2020 01:23:38 +0000
Bug 1657482 - Avoid unnecessary map lookups. r=kats Depends on D86082 Differential Revision: https://phabricator.services.mozilla.com/D86083
4cfd2bdd51dcafe59f9a59957e9d396d7507a254: Bug 1657482 - Use unique_ptr rather than raw new/delete. r=kats
Botond Ballo <botond@mozilla.com> - Thu, 06 Aug 2020 00:21:55 +0000 - rev 543518
Push 123509 by bballo@mozilla.com at Thu, 06 Aug 2020 01:23:38 +0000
Bug 1657482 - Use unique_ptr rather than raw new/delete. r=kats Differential Revision: https://phabricator.services.mozilla.com/D86082
f2886b1341e7dc3ebf5053328ed728c28a7b3b03: Bug 1654933. Make ScrollFrameHelper::GetScrollRangeForUserInputEvents return a range that encompasses the visual viewport offset even if we are overflow: hidden. r=kats
Timothy Nikkel <tnikkel@gmail.com> - Wed, 05 Aug 2020 17:55:29 +0000 - rev 543507
Push 123498 by tnikkel@mozilla.com at Wed, 05 Aug 2020 22:47:13 +0000
Bug 1654933. Make ScrollFrameHelper::GetScrollRangeForUserInputEvents return a range that encompasses the visual viewport offset even if we are overflow: hidden. r=kats Depends on D85983 Differential Revision: https://phabricator.services.mozilla.com/D85984
475381b12bd54a5f2e19ca1627134d4a56a0b32e: Bug 1654933. ScrollFrameHelper::CurPosAttributeChanged should be using the scroll range not the scroll rect. r=kats
Timothy Nikkel <tnikkel@gmail.com> - Wed, 05 Aug 2020 17:56:12 +0000 - rev 543506
Push 123498 by tnikkel@mozilla.com at Wed, 05 Aug 2020 22:47:13 +0000
Bug 1654933. ScrollFrameHelper::CurPosAttributeChanged should be using the scroll range not the scroll rect. r=kats UpdateScrollbarPosition and ReflowFinished both use the scroll range for this. It usually doesn't matter, but the next patch will make it important. Differential Revision: https://phabricator.services.mozilla.com/D85983
262aea7f68099386850ea9aba7c3fb76f42571a7: Bug 1652750 - Add WR stack overflow test r=kats
Dzmitry Malyshau <dmalyshau@mozilla.com> - Wed, 05 Aug 2020 20:07:03 +0000 - rev 543479
Push 123480 by dmalyshau@mozilla.com at Wed, 05 Aug 2020 20:09:35 +0000
Bug 1652750 - Add WR stack overflow test r=kats adds the gfx crashtest that kats produced Differential Revision: https://phabricator.services.mozilla.com/D85875
08c512440c1b8aa80a4483fca59c888e8c88a903: Bug 1657073. Make sure to destroy direct manipulation objects before we clear our HWND pointer. r=kats
Timothy Nikkel <tnikkel@gmail.com> - Tue, 04 Aug 2020 12:13:50 +0000 - rev 543254
Push 123341 by kgupta@mozilla.com at Tue, 04 Aug 2020 17:46:35 +0000
Bug 1657073. Make sure to destroy direct manipulation objects before we clear our HWND pointer. r=kats Otherwise when we try to call Deactivate on the direct manipulation manager (to balance the Activate call) we won't have the HWND pointer and so it won't balance and we will leak. We call DestroyDirectManipulation in nsWindow::Destroy but it looks like nsWindow::OnDestroy can be called before nsWindow::Destroy. Differential Revision: https://phabricator.services.mozilla.com/D85835
48fda512aea4df9dd225d14858e3e742344365be: Bug 1656998 - Adjust fuzzy annotations for reftests which became less fuzzy after toolchain and images got rebuilt. r=kats
Sebastian Hengst <archaeopteryx@coole-files.de> - Tue, 04 Aug 2020 12:59:21 +0000 - rev 543220
Push 123313 by archaeopteryx@coole-files.de at Tue, 04 Aug 2020 15:04:10 +0000
Bug 1656998 - Adjust fuzzy annotations for reftests which became less fuzzy after toolchain and images got rebuilt. r=kats Differential Revision: https://phabricator.services.mozilla.com/D85840
478b4aba016f2b494b6f287af0982e377bb10349: Bug 1655278 - Stop forcing a composite when we have fallen 2 vsync intervals behind. r=kats
Jamie Nicol <jnicol@mozilla.com> - Fri, 31 Jul 2020 17:53:27 +0000 - rev 542967
Push 123138 by jnicol@mozilla.com at Fri, 31 Jul 2020 21:08:42 +0000
Bug 1655278 - Stop forcing a composite when we have fallen 2 vsync intervals behind. r=kats Currently on Android when CompositorVsyncScheduler detects that we requested a composite more than 2 vsync intervals ago it forces an immediate composite. This is a relic from times when vsync observation occured on the main thread, and Fennec was single-process. (The logic being that if the main thread was busy and it would be better to composite immediately rather than wait for the vsync notification.) Neither of these conditions are true nowadays, and geckoview should be no worse than desktop platforms in this regard, so let's remove this code. Depends on D85611 Differential Revision: https://phabricator.services.mozilla.com/D85612
d6cfdf681c346e69ec6ac12effe56661de8280d7: Bug 1655278 - Ensure AndroidVsyncSource::Display::mVsyncDuration is initialized before CompositorBridgeParent. r=kats
Jamie Nicol <jnicol@mozilla.com> - Fri, 31 Jul 2020 17:49:10 +0000 - rev 542966
Push 123138 by jnicol@mozilla.com at Fri, 31 Jul 2020 21:08:42 +0000
Bug 1655278 - Ensure AndroidVsyncSource::Display::mVsyncDuration is initialized before CompositorBridgeParent. r=kats When a CompositorBridgeParent is initialized it reads the vsync duration from the AndroidVsyncSource::Display instance. The vsync duration is currently initialized in AndroidVsyncSource::EnableVsync(). Since bug 1617750 landed, which makes the hidden window lazily loaded, the first tab's CompositorBridgeParent is being initialized before vsync is enabled, meaning it reads a value of zero. Instead, initialize mVsyncDuration in the AndroidVsyncSource::Display constructor. Differential Revision: https://phabricator.services.mozilla.com/D85611
268fe244132f7681470a859c62a1928e2d7941f4: Bug 1655376 - Fix early rounding of iframe origin for WR. r=kats,aosmond
Glenn Watson <git@intuitionlibrary.com> - Wed, 29 Jul 2020 13:09:53 +0000 - rev 542513
Push 122928 by gwatson@mozilla.com at Wed, 29 Jul 2020 20:20:01 +0000
Bug 1655376 - Fix early rounding of iframe origin for WR. r=kats,aosmond WR handles snapping of primitives and clips, and prefers the input data to be exact floats. This fixes an inconsistency between the clip and bounds of iframes in WR when there is a fractional device-pixel ratio set. Differential Revision: https://phabricator.services.mozilla.com/D85219
1e36ce18138c9323e0341a08a9ea2192f87e757c: Bug 1655242. When a relative scroll offset update comes in during a smooth scroll animation make the new destination be based on the existing destination, not the current scroll position. r=kats
Timothy Nikkel <tnikkel@gmail.com> - Wed, 29 Jul 2020 05:23:17 +0000 - rev 542436
Push 122868 by tnikkel@mozilla.com at Wed, 29 Jul 2020 05:31:29 +0000
Bug 1655242. When a relative scroll offset update comes in during a smooth scroll animation make the new destination be based on the existing destination, not the current scroll position. r=kats Differential Revision: https://phabricator.services.mozilla.com/D84904
00a02a6867245e67d5ac4975703dc6c01dc8ed45: Bug 1655780. Hold mutex while accessing mState in AsyncPanZoomController::HandleDragEvent. r=kats
Timothy Nikkel <tnikkel@gmail.com> - Wed, 29 Jul 2020 01:44:45 +0000 - rev 542434
Push 122866 by tnikkel@mozilla.com at Wed, 29 Jul 2020 05:17:05 +0000
Bug 1655780. Hold mutex while accessing mState in AsyncPanZoomController::HandleDragEvent. r=kats Differential Revision: https://phabricator.services.mozilla.com/D85214
37c23ef47c31b60eb0f0d1d000af1d5d64fb333b: Bug 1625249 - test hittest with SVG in parent over OOP iframe. r=kats
Yura Zenevich <yura.zenevich@gmail.com> - Wed, 29 Jul 2020 02:27:43 +0000 - rev 542426
Push 122858 by yura.zenevich@gmail.com at Wed, 29 Jul 2020 02:31:33 +0000
Bug 1625249 - test hittest with SVG in parent over OOP iframe. r=kats Differential Revision: https://phabricator.services.mozilla.com/D69664
988343da285bd5f2041ea6afb77a5f9f88e039c6: Bug 1653986 - Add new test metadata taskcluster searchfox task deps. r=kats
Andrew Sutherland <asutherland@asutherland.org> - Tue, 28 Jul 2020 09:59:02 +0000 - rev 542382
Push 122821 by bugmail@asutherland.org at Tue, 28 Jul 2020 17:31:40 +0000
Bug 1653986 - Add new test metadata taskcluster searchfox task deps. r=kats The enhancements in Bug 1653986 to display information about tests derives its data from these 2 jobs and so it's appropriate to explicitly depend on them. The current status of these jobs in the tree as far as I can tell is that: - "source-test-file-metadata-test-info-all": Seems to get automatically triggered by someone's regularly, so it's always likely to be there for our searchfox cron jobs, but it's nice to not depend on that. - "source-test-wpt-metadata-summary" : Seems to get automatically run, but only on commits that touch meta files change, per https://searchfox.org/mozilla-central/rev/cf561cece0ca9aeaf0202e68699836d957d0c670/taskcluster/ci/source-test/wpt-metadata.yml#31 and indeed it wasn't there on today's searchfox jobs. Differential Revision: https://phabricator.services.mozilla.com/D84933
941edd025d9ae9cae605bd24c33d47de3bffcfdc: Bug 1655160. Disable new desktop zooming scrollbar code for now. r=kats
Timothy Nikkel <tnikkel@gmail.com> - Fri, 24 Jul 2020 20:10:10 +0000 - rev 542104
Push 122641 by tnikkel@mozilla.com at Fri, 24 Jul 2020 20:15:48 +0000
Bug 1655160. Disable new desktop zooming scrollbar code for now. r=kats Differential Revision: https://phabricator.services.mozilla.com/D84861
6072f44b8de8fd449843f6bd54ee9ef294875e71: Bug 1653615 - Ensure displayport snapping doesn't move by more than the margin. r=kats
Nicolas Silva <nsilva@mozilla.com> - Fri, 24 Jul 2020 07:09:47 +0000 - rev 541904
Push 122564 by nsilva@mozilla.com at Fri, 24 Jul 2020 07:58:22 +0000
Bug 1653615 - Ensure displayport snapping doesn't move by more than the margin. r=kats Differential Revision: https://phabricator.services.mozilla.com/D84552
05066c66156cd3612dea3eef715bf718c4f083f2: Bug 1653615 - Add a test. r=kats
Nicolas Silva <nsilva@mozilla.com> - Thu, 23 Jul 2020 13:50:10 +0000 - rev 541903
Push 122564 by nsilva@mozilla.com at Fri, 24 Jul 2020 07:58:22 +0000
Bug 1653615 - Add a test. r=kats Differential Revision: https://phabricator.services.mozilla.com/D84659
138e7b575614cbfc1e45576a15825f51cb6e6614: Bug 1651332. Use purely relative scroll offset updates for many scrollbar initiated scrolls. r=kats
Timothy Nikkel <tnikkel@gmail.com> - Sun, 19 Jul 2020 14:56:24 +0000 - rev 541740
Push 122450 by tnikkel@mozilla.com at Thu, 23 Jul 2020 02:24:10 +0000
Bug 1651332. Use purely relative scroll offset updates for many scrollbar initiated scrolls. r=kats This patch basically attempts to make clicking in the scrollbar track outside of the scrollthumb "work". Clicking in the scrollbar track usually does a page scroll via nsSliderFrame::PageScroll. This eventually ends up in ScrollFrameHelper::ScrollBy where we turn the request from a relative one ("scroll by a page") into an absolute one ("scroll to this position"). This page scroll is typically a smooth scroll and is currently done on the main thread/layout side. Once we start scrolling the visual viewport offset with the scrollbars we can no longer do this purely on the layout side, we at least need the help of the compositor side. I think the simplest way to do this is to hand the scroll request off to the compositor and have it handle the whole thing. Now we need to consider the following situation: user clicks scrollbar track to page scroll, smooth scroll gets partway complete on the compositor, user clicks again on scrollbar track for a further page scroll. The main thread can't send an absolute scroll offset update request to the compositor at this point because it has outdated information (it needs a 'starting position' to add the page scroll offset amount) so it'll end up scrolling to the wrong place. It has to send a relative scroll offset update. We already have a mechanism to send relative scroll offset updates. It is implemented by sending a base scroll offset and the desired scroll offset, and then on the compositor send the difference between those two is computed and then added to the scroll offset. This patch creates a new mechanism (so called "pure relative") that just sends a relative offset update without any absolute scroll positions. The reason I did this is because the existing relative scroll offset update mechanism is not aware of visual viewport offsets, but rather only layout scroll position. For example, here https://searchfox.org/mozilla-central/rev/8d55e18875b89cdf2a22a7cba60dc40999c18356/layout/generic/nsGfxScrollFrame.h#446 the value we use for the base scroll offset (mApzScrollPos) is set to the layout scroll position. It may be entirely reasonable to make this existing mechanism vv offset aware, but I wanted to implement something to get it working with a smaller chance of regressions to things that already exist and work. Ideally these two mechanims would be merged. Differential Revision: https://phabricator.services.mozilla.com/D82688
8309d62060f015ef83c67da5b6cee8e2a000840f: Bug 1651332. Update scrollbar position when the visual viewport offset changes. r=kats
Timothy Nikkel <tnikkel@gmail.com> - Sun, 19 Jul 2020 10:04:42 +0000 - rev 541739
Push 122450 by tnikkel@mozilla.com at Thu, 23 Jul 2020 02:24:10 +0000
Bug 1651332. Update scrollbar position when the visual viewport offset changes. r=kats The scrollbar is now positioned using the visual viewport offset, so we need to update when that changes. Differential Revision: https://phabricator.services.mozilla.com/D82687
251aa3acc01fba6521c5d03cedf7ae120b2923c2: Bug 1651332. Update how the compositor adjust scroll thumbs. r=kats
Timothy Nikkel <tnikkel@gmail.com> - Sun, 19 Jul 2020 10:04:24 +0000 - rev 541738
Push 122450 by tnikkel@mozilla.com at Thu, 23 Jul 2020 02:24:10 +0000
Bug 1651332. Update how the compositor adjust scroll thumbs. r=kats Now that layout places the scroll thumbs at the visual viewport offset instead of the layout scroll position we need to update how the compositor adjusts them. Differential Revision: https://phabricator.services.mozilla.com/D82686
c99841ff8519642bdacdcde978e72712900e020a: Bug 1651332. Update scrollbar attrs to use visual viewport offset. r=kats
Timothy Nikkel <tnikkel@gmail.com> - Sun, 19 Jul 2020 10:04:17 +0000 - rev 541737
Push 122450 by tnikkel@mozilla.com at Thu, 23 Jul 2020 02:24:10 +0000
Bug 1651332. Update scrollbar attrs to use visual viewport offset. r=kats Differential Revision: https://phabricator.services.mozilla.com/D82685
d71765b6908fa8d8caa9d0b9c2e3422195504cd5: Bug 1651332. Create a pref to gate the new scrollbar code on. r=kats
Timothy Nikkel <tnikkel@gmail.com> - Sun, 19 Jul 2020 10:04:04 +0000 - rev 541736
Push 122450 by tnikkel@mozilla.com at Thu, 23 Jul 2020 02:24:10 +0000
Bug 1651332. Create a pref to gate the new scrollbar code on. r=kats I could have use apz.allow_zooming but using a separate pref means we can flip the pref to check if the new scrollbar code is the source of a regression. Also I haven't tested the code on Fenix at all, so we can disable it there for now. Differential Revision: https://phabricator.services.mozilla.com/D82684
9c57e70c264dce03f1cb9129fc1f9504b098ff2b: Bug 1650719 - Don't lose the rect offset from the composition bounds. r=kats
Emilio Cobos Álvarez <emilio@crisal.io> - Wed, 22 Jul 2020 22:02:35 +0000 - rev 541717
Push 122435 by ealvarez@mozilla.com at Wed, 22 Jul 2020 22:20:05 +0000
Bug 1650719 - Don't lose the rect offset from the composition bounds. r=kats This offset was reset in one of the two codepaths of D80723, but turns out it's important for same-origin documents that are also root-content-documents, like about: pages in the parent process, which happened to hit the codepath that did _not_ reset it. :( Differential Revision: https://phabricator.services.mozilla.com/D84584
852e6d790ba25e4eebfba05c24a5c8f395c8d923: Bug 1654233 - add new dump syms to Android searchfox builds; r=kats
Nathan Froyd <froydnj@mozilla.com> - Tue, 21 Jul 2020 13:39:27 +0000 - rev 541439
Push 122245 by nfroyd@mozilla.com at Tue, 21 Jul 2020 13:40:24 +0000
Bug 1654233 - add new dump syms to Android searchfox builds; r=kats This build was missed in the previous update. Differential Revision: https://phabricator.services.mozilla.com/D84347
0e9f81e8dcf306c209230eaf572ad307de017390: Bug 1638152 - Jank partial prerender transform animations and report the janked animations to the main-thread in each process on WebRender. r=botond,kats
Hiroyuki Ikezoe <hikezoe.birchill@mozilla.com> - Tue, 21 Jul 2020 10:03:34 +0000 - rev 541417
Push 122228 by hikezoe.birchill@mozilla.com at Tue, 21 Jul 2020 10:10:01 +0000
Bug 1638152 - Jank partial prerender transform animations and report the janked animations to the main-thread in each process on WebRender. r=botond,kats Differential Revision: https://phabricator.services.mozilla.com/D83202
12ac6d0d07ab39f82b77e6c09de7ef2ee05eb0e8: Bug 1650990 - Add the provided test case as a crashtest. r=kats
Nicolas Silva <nsilva@mozilla.com> - Mon, 20 Jul 2020 13:03:41 +0000 - rev 541266
Push 122149 by nsilva@mozilla.com at Mon, 20 Jul 2020 15:49:55 +0000
Bug 1650990 - Add the provided test case as a crashtest. r=kats Differential Revision: https://phabricator.services.mozilla.com/D84157
bd88950d6cec27e509e67087a8a737e051f9a4d2: Bug 1653700. Populate PanGestureInput::mLineOrPageDeltaX/Y when the events are produced from direct manipulation. r=kats
Timothy Nikkel <tnikkel@gmail.com> - Sat, 18 Jul 2020 20:47:04 +0000 - rev 541152
Push 122074 by tnikkel@mozilla.com at Sun, 19 Jul 2020 03:54:15 +0000
Bug 1653700. Populate PanGestureInput::mLineOrPageDeltaX/Y when the events are produced from direct manipulation. r=kats The macOS widget code already does this here https://searchfox.org/mozilla-central/rev/d6d8fcc22c3820f2ae08229e0d37be19fba74db9/widget/cocoa/nsChildView.mm#3491 So we factor our a helper from the macOS widget code (which already does this) to use cross platform. Differential Revision: https://phabricator.services.mozilla.com/D84059
c62a113bc9dbb89def4f6212d639a103fc48206e: Bug 1652825 - Add BaseTransactionId::operator!=. r=kats
Markus Stange <mstange.moz@gmail.com> - Tue, 14 Jul 2020 18:13:12 +0000 - rev 540442
Push 121714 by mstange@themasta.com at Tue, 14 Jul 2020 18:24:22 +0000
Bug 1652825 - Add BaseTransactionId::operator!=. r=kats Differential Revision: https://phabricator.services.mozilla.com/D83547
bee4101b3fd6d3a32054574dec4e5a0dcf3db5d5: Bug 1651910 - Use only AnimationTransform::mFrameTransform for WebRender. r=kats
Hiroyuki Ikezoe <hikezoe.birchill@mozilla.com> - Tue, 14 Jul 2020 02:31:11 +0000 - rev 540326
Push 121631 by hikezoe.birchill@mozilla.com at Tue, 14 Jul 2020 02:32:02 +0000
Bug 1651910 - Use only AnimationTransform::mFrameTransform for WebRender. r=kats With the previous change, on WebRender AnimationTransform::mTransformInDevSpace and AnimationTransform::mFrameTransform are pretty much same, so we don't need to set both of values, we need only mFrameTransform. Also this patch drops move(s), I didn't know that Matrix4x4 can't be moved. Differential Revision: https://phabricator.services.mozilla.com/D83041
86e7658cfe8d6a10131dd7ded8701431d7b5a08d: Bug 1651910 - Drop inherited scale values and hasPerspectiveParent in TransformData. r=kats
Hiroyuki Ikezoe <hikezoe.birchill@mozilla.com> - Tue, 14 Jul 2020 02:28:36 +0000 - rev 540325
Push 121631 by hikezoe.birchill@mozilla.com at Tue, 14 Jul 2020 02:32:02 +0000
Bug 1651910 - Drop inherited scale values and hasPerspectiveParent in TransformData. r=kats They haven't been used effectively since bug 1403915. Differential Revision: https://phabricator.services.mozilla.com/D83040
f5b8321f3160e90b6e4227c4943ad1e57dbe1f38: Bug 1651910 - Fix non unified build errors in OMTASampler. r=kats
Hiroyuki Ikezoe <hikezoe.birchill@mozilla.com> - Tue, 14 Jul 2020 02:28:26 +0000 - rev 540324
Push 121631 by hikezoe.birchill@mozilla.com at Tue, 14 Jul 2020 02:32:02 +0000
Bug 1651910 - Fix non unified build errors in OMTASampler. r=kats Differential Revision: https://phabricator.services.mozilla.com/D83039
4e42d8d4df9d84afc65a4745ea56d3c5aaf9a36f: Bug 1324591 - Store the corresponding LayersId for each animation on the compositor. r=kats
Hiroyuki Ikezoe <hikezoe.birchill@mozilla.com> - Sun, 05 Jul 2020 11:42:55 +0000 - rev 538842
Push 120767 by hikezoe.birchill@mozilla.com at Sun, 05 Jul 2020 11:55:18 +0000
Bug 1324591 - Store the corresponding LayersId for each animation on the compositor. r=kats Depends on D75727 Differential Revision: https://phabricator.services.mozilla.com/D75728
8e6d4e9f5aa09b1fe97aa4994af77aa812f3ca1c: Bug 1324591 - Store the corresponding LayersId for each animation on the compositor. r=kats
Hiroyuki Ikezoe <hikezoe.birchill@mozilla.com> - Sun, 05 Jul 2020 02:48:51 +0000 - rev 538830
Push 120763 by hikezoe.birchill@mozilla.com at Sun, 05 Jul 2020 03:49:02 +0000
Bug 1324591 - Store the corresponding LayersId for each animation on the compositor. r=kats Differential Revision: https://phabricator.services.mozilla.com/D75728
3eea2c35d0c4cf1a2a976b66df9b604ae63a5d21: Bug 1552923 - Clear out the last animated value if a new animation with the same id arrived and sampled but didn't produce any animated value. r=kats
Hiroyuki Ikezoe <hikezoe.birchill@mozilla.com> - Fri, 03 Jul 2020 21:42:06 +0000 - rev 538805
Push 120746 by hikezoe.birchill@mozilla.com at Fri, 03 Jul 2020 21:42:33 +0000
Bug 1552923 - Clear out the last animated value if a new animation with the same id arrived and sampled but didn't produce any animated value. r=kats A reftest for this issue will be added in bug 1650351. Differential Revision: https://phabricator.services.mozilla.com/D82172
d23fbb1a4fd8c8f3b5e881e4ad4927f93d2675f8: Bug 1648630 - Part 3: Propagate layers id to touch event properly for Fission; r=kats
Edgar Chen <echen@mozilla.com> - Fri, 03 Jul 2020 07:45:35 +0000 - rev 538577
Push 120669 by echen@mozilla.com at Fri, 03 Jul 2020 07:47:31 +0000
Bug 1648630 - Part 3: Propagate layers id to touch event properly for Fission; r=kats Differential Revision: https://phabricator.services.mozilla.com/D81869
e5c2bc278f07477d3427387d1eb55ba80ea9ad2f: Bug 1648630 - Part 2: Use EvictTouches to evict old touches; r=kats
Edgar Chen <echen@mozilla.com> - Thu, 02 Jul 2020 19:27:51 +0000 - rev 538576
Push 120669 by echen@mozilla.com at Fri, 03 Jul 2020 07:47:31 +0000
Bug 1648630 - Part 2: Use EvictTouches to evict old touches; r=kats Differential Revision: https://phabricator.services.mozilla.com/D81825