1858610 - Make helper_{bug1285070,bug1299195,bug1502010_unconsumed_pan}.html pass reliably on Android

Status: RESOLVED FIXED

(Core :: Panning and Zooming, task, P2)

Description

[Botond Ballo [:botond]]

In bug 1776964 we have identified 3 subtests of test_group_pointerevents.html which have frequent intermittent failures on Android.

In bug 1776964, I'm going to disable these tests on Android. This bug tracks investigating the cause of the intermittent failures and re-enabling the tests on Android.

Comment 1

[Botond Ballo [:botond]]

(In reply to Botond Ballo [:botond] from comment #0)

In bug 1776964, I'm going to disable these tests on Android.

(I guess I should do it in a separate bug, since bug 1776964 is the "single tracking bug" for the test group. I will do it in bug 1858611.)

Comment 2

[Botond Ballo [:botond]]

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 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 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.)

Comment 3

[Hiroyuki Ikezoe (:hiro)]

It turned out that using DispatchToGeckoPriorityQueue wasn't sufficient to ensure the event arrival order because of our touch resampling machinery.

The touch-end event in question is dispatched in a Vsync tick in the browser parent process. Sometimes, i.e. in failure cases, the single-tap message is dispatched before the Vsync tick unfortunately. CCing Markus.

Comment 4

[Hiroyuki Ikezoe (:hiro)]

Forgot a link to a try push with disabling android.touch_resampling.enabled to do double-check whether the touch resampling machinery affects these test failures. There were no failure; https://treeherder.mozilla.org/jobs?repo=try&revision=0729f4a95a17e54b661b4bd77e019d358e999caa

Comment 5

[Dan Robertson (:dlrobertson)]

I'll start looking into this tomorrow

Comment 6

[Dan Robertson (:dlrobertson)]

Attachment: Bug 1858610 - touch-end should be received before firing single-tap events. r=hiro,botond

Before firing synthesized mouse events for a single tap gesture, ensure
that the touch-end has been fired.

Comment 7

[Dan Robertson (:dlrobertson)]

Attachment: Bug 1858610 - Move HandleTap from the APZCTreeManager to the InputBridge protocol. r=hiro,botond

The HandleTap message should be part of the InputBridge protocol to
ensure that the synthesized click events are sent to content after the
corresponding touch-end.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/88c0e8c08c4a
Move HandleTap from the APZCTreeManager to the InputBridge protocol. r=botond

Comment 9

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/88c0e8c08c4a