I've been able to reproduce this on a Nexus 7.

tools/perf/run_benchmark --browser=android-content-shell smoothness.sync_scroll.key_mobile_sites_smooth --story-filter="michelle"

The test is failing when I pass --profiler=trace though...

Ah, forgot the magic to get a trace as well:

tools/perf/run_benchmark --browser=android-content-shell smoothness.sync_scroll.key_mobile_sites_smooth --story-filter="michelle" --output-format=json --output-dir=~/Desktop/missing-gsus/
# in timeline_based_measurement.py (third_party/catapult)
class Options::__init__
overhead_level = DEBUG_OVERHEAD_LEVEL

Trace attached, missing GSUs.

This should be straight forward to debug, now that I have a repro.

Deleted: http___www_cnn_com_2012_10_03_politics_michelle_obama_debate_index_html0.html 5.8 MB

http___www_cnn_com_2012_10_03_politics_michelle_obama_debate_index_html0.html 5.8 MB View Download

I have two independent ways of repro'ing this on N7:
The easy one is to run the test with the display off. I'm not sure why this causes the input pipeline to not work.

Is there any chance this is what's effecting the N9's?

The other repro only occurs rarely. I'm seeing the gesture provider generate gestures, and we generate LatencyInfo for the touchmove events.

The RWHI never forwards the gestures though.

+Randy: does the device staus check make sure that the display is on?

The device status check does not do anything other than report the status of the device. Provision Devices and/or device recovery would be the steps that should ensure that the screen is on; it does not appear either do though.


But, platform mode (which is now the default way to run perf tests, so is used everywhere) does ensure the screen is on before every test is run.

https://cs.chromium.org/chromium/src/build/android/pylib/local/device/local_device_perf_test_run.py?type=cs&q=f:build/android+IsScreenOn&sq=package:chromium&l=267

Clarification: platform mode is run via build/android/test_runner.py perf <flags here> and is the default way to run perf tests on the bots.

At least one of the smoothness tests contains an input element, which prevents scrolling if the pointer lands on it.

I'm not sure how common this is, but we should figure out a good way of fixing it.

Options:
• Have a mode where pages can't prevent scrolling.
• Move the point where we touch the page.
• Stick a div on top of the page, and touch inside it.
• Try to automate finding a good place to touch the page to scroll it.
• Flag cases where touches are preventDefaulted but shouldn't be, making this easy to identify, and deal with on a case by case basis.

nd content_shell_apk && tools/perf/run_benchmark --browser=android-content-shell smoothness.sync_scroll.key_mobile_sites_smooth --story-filter="michelle" --output-format=json --output-dir=~/Desktop/missing-gsus/

Would there be an easy way of checking which tests execute a specific line of code on the bots?

To comment in #9, the easiest way is add logging at that line & check the log on bots. 

Can you also explain how can the focus be in the input element if we never tells telemetry to click on it?

If we start a scroll by touching on the input element, then we never scroll.

There's no notion of focus that matters here (for touch scrolling).

I see. I think the best fix is probably throws exception if the scroll fails, so people can be aware & fix them when there is some problem (option 5).

Where in the infrastructure would that exception be thrown?
Is that part of the trace analysis?

I think it should throw exception right away when we issue the scroll action and the page doesn't move.

Currently, we just verify that the scroll action is done by using register a callback on chrome.gpuBenchmarking.smoothScrollBy method (https://github.com/catapult-project/catapult/blob/master/telemetry/telemetry/internal/actions/scroll.py#L106).

I think easy fix could be adding some extra js to check whether the page has moved.

It's a bit tricky, because not all scrolls will necessarily scroll the page, for instance if there's a nested div. Determining what should have scrolled might be a bit tricky.

We might want to throw if we've scrolled, but didn't get any GestureScrollUpdate latency slices?

That seems right but the check for "whether GestureScrollUpdate " can only be done through Chrome side? Since using chrome.gpuBenchmarking.smoothScrollBy is also a code debt that hasn't been paid off (we should use devtool API instead), I think we can move the check to the metric time, i.e: when we compute smoothness metric, we can throw exception when we detect synthetic scroll region that do not have any "GestureScrollUpdate latency slices"?

I think that might be equivalent to throwing an exception on a data stoppage of this measurement. I guess the difference is that it would make the bots go red, instead of raising a data stoppage alert?

Alternatively, we could look through the trace for cases where people are calling preventDefault, which is a bit more fine grained than just "didn't scroll". In most cases they're equivalent I suppose though. Maybe even always?

Blocking bugs are all closed.