Writing this down for future reference: Hiro did some investigation of this and found that the issue is related to a single-tap messages incorrectly arriving to the content process sooner than the touch-end event which generated that tap. We take some measures to ensure these arrive in the correct order, specifically: 1. In `AsyncPanZoomController::GenerateSingleTap`, we [schedule](https://searchfox.org/mozilla-central/rev/81a006cd60c54ce074d7158fafc5a2923717860e/gfx/layers/apz/src/AsyncPanZoomController.cpp#3093-3098) the `GeckoContentController::HandleTap` call to happen on the next iteration of the event loop, since we may be in the middle of processing the touch-end. 2. When the GPU process is used, in `RemoteContentController`, we [bounce](https://searchfox.org/mozilla-central/rev/81a006cd60c54ce074d7158fafc5a2923717860e/gfx/layers/ipc/RemoteContentController.cpp#88-93) the single-tap notification through the parent process (using `PAPZCTreeManager`), so that it takes the IPC message path as the originated touch events, and does not reach the content process sooner than those touch events. However, it's possible that these measures fail to take into account some scenarios. In particular, I'm pretty sure they pre-date the enablement of the GPU process on **Android** (which is where these tests are failing), where the setup might be slightly different. (Not sure whether this applies to all the subtests or just some of them.)
Bug 1858610 Comment 2 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Writing this down for future reference: Hiro did some investigation of this and found that the issue is related to a single-tap message incorrectly arriving to the content process sooner than the touch-end event which generated that tap. We take some measures to ensure these arrive in the correct order, specifically: 1. In `AsyncPanZoomController::GenerateSingleTap`, we [schedule](https://searchfox.org/mozilla-central/rev/81a006cd60c54ce074d7158fafc5a2923717860e/gfx/layers/apz/src/AsyncPanZoomController.cpp#3093-3098) the `GeckoContentController::HandleTap` call to happen on the next iteration of the event loop, since we may be in the middle of processing the touch-end. 2. When the GPU process is used, in `RemoteContentController`, we [bounce](https://searchfox.org/mozilla-central/rev/81a006cd60c54ce074d7158fafc5a2923717860e/gfx/layers/ipc/RemoteContentController.cpp#88-93) the single-tap notification through the parent process (using `PAPZCTreeManager`), so that it takes the IPC message path as the originated touch events, and does not reach the content process sooner than those touch events. However, it's possible that these measures fail to take into account some scenarios. In particular, I'm pretty sure they pre-date the enablement of the GPU process on **Android** (which is where these tests are failing), where the setup might be slightly different. (Not sure whether this applies to all the subtests or just some of them.)
Writing this down for future reference: Hiro did some investigation of this and found that the issue is related to a single-tap message incorrectly arriving to the content process sooner than the touch-end event which generated that tap. We take some measures to ensure these arrive in the correct order, specifically: 1. In `AsyncPanZoomController::GenerateSingleTap`, we [schedule](https://searchfox.org/mozilla-central/rev/81a006cd60c54ce074d7158fafc5a2923717860e/gfx/layers/apz/src/AsyncPanZoomController.cpp#3093-3098) the `GeckoContentController::HandleTap` call to happen on the next iteration of the event loop, since we may be in the middle of processing the touch-end. 2. When the GPU process is used, in `RemoteContentController`, we [bounce](https://searchfox.org/mozilla-central/rev/81a006cd60c54ce074d7158fafc5a2923717860e/gfx/layers/ipc/RemoteContentController.cpp#88-93) the single-tap notification through the parent process (using `PAPZCTreeManager`), so that it takes the same IPC message path as the originated touch events, and does not reach the content process sooner than those touch events. However, it's possible that these measures fail to take into account some scenarios. In particular, I'm pretty sure they pre-date the enablement of the GPU process on **Android** (which is where these tests are failing), where the setup might be slightly different. (Not sure whether this applies to all the subtests or just some of them.)
Writing this down for future reference: Hiro did some investigation of this and found that the issue is related to a single-tap message incorrectly arriving to the content process sooner than the touch-end event which generated that tap. We take some measures to ensure these arrive in the correct order, specifically: 1. In `AsyncPanZoomController::GenerateSingleTap`, we [schedule](https://searchfox.org/mozilla-central/rev/81a006cd60c54ce074d7158fafc5a2923717860e/gfx/layers/apz/src/AsyncPanZoomController.cpp#3093-3098) the `GeckoContentController::HandleTap` call to happen on the next iteration of the event loop, since we may be in the middle of processing the touch-end. 2. When the GPU process is used, in `RemoteContentController`, we [bounce](https://searchfox.org/mozilla-central/rev/81a006cd60c54ce074d7158fafc5a2923717860e/gfx/layers/ipc/RemoteContentController.cpp#88-93) the single-tap notification through the parent process (using `PAPZCTreeManager`), so that it takes the same IPC message path as the originating touch events, and does not reach the content process sooner than those touch events. However, it's possible that these measures fail to take into account some scenarios. In particular, I'm pretty sure they pre-date the enablement of the GPU process on **Android** (which is where these tests are failing), where the setup might be slightly different. (Not sure whether this applies to all the subtests or just some of them.)