There is a strong desire to measure the input latency of geckoview. What is input latency, it could mean a variety of things and there have been many discussions to try to define what it means. For the purposes of an actionable bug, we need to pick some actions related to a user interacting with geckoview and ensure we can measure any lag that is there. Here is a non comprehensive list of actions we should consider measuring: * taps * scrolls * pinch/zoom * swipe * long press * key press I would imagine this list is in order of priority- can we get the first 2 or 3 to make this a more realistic bug to resolve? For writing this test, i am not sure if we need a tool that runs at the OS level, or some hack into our browser that simulates touch events. My main intention is to get this bug on file so we can start making this actionable and getting a test created that can be handed over to my team so we can get it running in automation (assuming that is the right path)

Thanks Joel. Ehsan do you have thoughts on how we should measure input latency? Perhaps we've thought about this for desktop as well?

We had a private email thread about this a while ago, titled "GeckoView and Input Latency". Here are some thoughts from there: * We have a few existing telemetry probes <https://telemetry.mozilla.org/probe-dictionary/?search=input_event>, we may need to add more for touch events. * We may need to add new probes for other types of feedback such as the haptick feedback. * For writing the tests, the closer our simulations are to the OS (so that more of our code gets examined) the better, but I think snorp would be a better person to talk about the specifics there. * The priority order that the Product and Product Integrity teams have agreed on is: taps, scrolls, pinch/zoom, swipe, long press, key press. If we have to pick any subset as a first post goal, let it be taps and scrolls. Hope this is helpful.

Thank you Ehsan! Vicky, I'm NI'ing you for awareness of this bug.

I find myself wondering whether this sort of automated test would be useful. For each of the proposed actions (tap, scroll, etc) there are probably other factors affecting input latency: What page are we tapping in, what element type, just once or multiple times, etc. If we are very careful to control all these factors in an automated test in a controlled hardware environment, we may be able to eliminate enough noise to identify regressions. But how much value is there in knowing the input latency of a button tap on google.com on a specific Pixel 2? Might we be better off putting our energy into monitoring tap input latency telemetry in the wild? If we do think there is value in such an automated test, have we discussed these other factors (maybe in the email Ehsan mentioned)? Can we specify some of those details here. ie tap - on what? scroll - what page (or what type of content is on the page)? scroll - how fast? etc.

Andreas, Vicky -- This bug seems to be languishing, and I think we need a clearer vision expressed here. Can you help define requirements? In addition to my questions in comment 4, :snorp recently pointed out that it is unclear what end time we should use: For a given input event, we want to measure *from* as close to the OS as possible, *to* ...?

https://groups.google.com/forum/#!topic/mozilla.dev.platform/-1qdVc7C2dM is an interesting discussion of a related topic.

The two input latency indicators we discussed duriing work week were scrolling and key presses. Joel already added the bug for scrolling above. Targeting scrolling would be a good first test to implement.

given that bug 1500465 is a P3 and appears to be a pre-requisite, are we safe to assume we are not in a position to work on this prior to the all hands in 2 weeks? If that is true, it is not realistic to have an input latency test written and rolled out by the end of the year.

Key press latency work is complete and the telemetry probe is being data reviewed. See bug 1506537. The framework for input latency was done under key press so that was the first to be completed. sphilp and I discussed extending the tp6-google suites tests to have user input via key press. Can we start with key press input latecy tests first?

we don't have the ability to run tp6 or other pageload on android right now, so for the purpose of this bug we would need to measure in another way. Looking in bug 1506537, I see some progress towards key press- this is a telemetry probe, we would need additional work (probably not much) to surface this to a perf test. I only ask the questions to see if measuring input latency (key press now) for geckoview we can finish up in the next 2 weeks, or if this is something that will get pushed into Q1 next year.

Since this is a GV bug, I don't think there is anything here for now until we have pageload in place to expand on. Keypress on desktop with gdocs would be the immediate action, with scrolling to follow on Android and then other events as possible (input latency is not a priority, but we should do the first two). The Keypress event work has landed so I think we can try to figure out a basic set of tests: * empty doc, wait for page load, send a keypress event and measure time to add character * 200 page test doc, wait for page load, send a keypress event and measure time to add character There are plenty other scenarios, like multiple clients in a doc each editing (Tarek had some ideas around solving this, but it's low priority for now), but it's not important to solve those right now.