Khushal, can you elaborate on what you mean here? It sounds like this bug is really about remoting touch input, not really a threading thing?

The terminology in chrome for scrolling performed by blink is main thread scrolling. Sorry if it created confusion here.

The bug is about the cases where the scroll/fling gesture can not be handled by the compositor. In chrome, it would be sent to blink on the main thread, but that would be an extremely jarring experience for blimp, since this would mean sending these gestures to blink on the engine. The bug is about what should be done for blimp in these cases. Currently we send them to the engine.

The list of such cases can be found here: https://cs.chromium.org/chromium/src/cc/input/main_thread_scrolling_reason.h

I had originally filed this bug after I ran into this case with google.com. Go to google.com, click on the app chooser on the top right and try to scrolling on it goes to the main thread. Some digging and it looks like the app chooser on google.com defers to main thread scrolling because of NonLayerViewportConstrainedObjects.

+rbyers, aelias who are the experts with blink scrolling. Could you explain what this reason precisely means and what necessitates falling back to it? I think this is something we would really want to change for blimp, if possible. I also looked at UMA, and close to half the cases for main thread scrolling on android are for this reason.

Sorry, my bad. The reason is different...

Obsolete, WontFix.