Hello

Thanks for reporting the issue. However, we get 'This item isn't available in your country' message. Can you please share a sample apk, along with a logcat/bugreport to help us with the issue?
 

We could download the apk and found the scrolling issue on M55.

Bisect range: https://chromium.googlesource.com/chromium/src/+log/55.0.2875.4..55.0.2880.3?pretty=fuller&n=10000

Logcat & videos @ http://go/chrome-androidlogs1/6/674415

Test team: can you take and upload traces before and after?

Christine, can someone do the traces as Bo asked in #4?

boliu@, I have added traces to http://go/chrome-androidlogs1/6/674415

Files added: trace_UBS_54.0.2840.85_trace.json
             trace_UBS_55.0.2883.91_trace.json

Is there any chance we get a fix for this behavior in webview 56? We found out that scrolling of pictures  with a different app also slowed down(https://play.google.com/store/apps/details?id=ch.iAgentur.i20Min&hl=de)

Tima, please see traces from ppolisetty@ in c3.

Narrowed range to: https://chromium.googlesource.com/chromium/src/+log/b0a6d1d..f38e25c?pretty=fuller&n=10000  (will do more on Tues)

Found breaking CL, this enabled Pointer Events API: https://codereview.chromium.org/2375493005

c#9: Thank you, Andrew!

Shall https://codereview.chromium.org/2375493005 be reverted? 

I don't think we're going to revert shipping pointer events from chromium generally at this point - it's a major launch that has now hit stable.

I guess someone will need to dig into this app to see why it's broken when pointer events are enabled and come up with some sort of mitigation strategy?  There's probably a bug in the app.  But we could explore adding a targetSdk quirk to enable pointer events (or the specific thing causing problems here) only for APKs built against a new SDK.

mustaq/dtapuska WDYT?

I'd like to understand the root cause of the slowness. Since ubs reported this directly to us I'd like to engaged them to see if we can somehow debug this app? Perhaps they are loading a library that is subscribing to pointer and touch events and doing double work now. 

Traditionally we've seen fastclick libraries that have been used inside APKs as well which aren't really necessary either.

The tracing shows many EventHandler::handleTouchEvent taking 30+ms, typically appears at the start of every touch interaction. Trying to dig further.

Deleted: Screenshot from 2016-12-20 16:29:25.png 43.9 KB

	Screenshot from 2016-12-20 16:29:25.png 43.9 KB View Download

Attaching my own traces. angler-userdebug 7.1.2 N2F68B 3554423 dev-keys
WebView 57.0.2958.0

The fast trace has WebRuntimeFeatures::enablePointerEvent(false).
Same app, same screen, same one scroll gesture.

So far I can only tell that in "slow scroll" the period during which VSyncs are coming is very short comparent to normal "fast" scroll: 200ms versus ~1.3s.
So "slow scroll" is actually short scroll.

Deleted: trace_fast-scroll.json 7.8 MB

trace_fast-scroll.json 7.8 MB View Download

Deleted: trace_slow-scroll.json 949 KB

trace_slow-scroll.json 949 KB View Download

Are you able to attach devtools and look at the source?  I don't have a custom version of Android webview to debug the app. And the app isn't a debug build so devtools doesn't attach. 

Yes, I can inspect the page.

Seems to be based on jQuery. <table class="mob-table mob-table-header mob-table-top">

I've seen this in the log while debugging:

"Blink deferred a task in order to make scrolling smoother. Your timer and network tasks should take less than 50ms to run to avoid this. Please see https://developers.google.com/web/tools/chrome-devtools/profile/evaluate-performance/rail and  https://crbug.com/574343#c40  for more information."

Can this be related to the problem?

Looks like some expensive timer tasks are being throttled, but as far as I can tell they're not related to the scrolling -- and the throttling turns off as soon as the touch gesture starts anyway.

In the the 'slow' trace it looks like the touch handlers are just eating the touch events without causing any animations to happen. Could it be that the touch handlers are just broken in some way when pointer events get enabled?

Another observation from timav's traces in #c15 above:

In the fast case, the first touchmove received by WebViewImpl::handleInputEvent (at 2,848,605ms) causes 3 calls to FrameView::layout from the touchmove handler.

In the slow case, the first touchmove received by WebViewImpl::handleInputEvent (at 2,011,826ms) does nothing comparable, from neither the pointermove handler nor the touchmove handler.

I suspect something very similar to what skyostil mentioned: perhaps both handlers bypass real work if PointerEvents enabled.

Analysis from our side: New webview 55 messes up scrolling in Cordova-based Android applications which use the newer versions of the iscroll library[1]. The problem is related to the handling of pointer-events in iscroll, and the recent introduction of pointer events [2, 3] in Webview 55.

AFAIK pointer events were introduced in Webview 51, but this is the first time it caused problems for us. We didn't receive bug reports for earlier versions.

Question: is there an option to release a plugin for webview that disables pointer events (Not sure if webview is pluginable) That way the affected users could just install the plugin and problem is solved...

iscroll is aware of the problem in their pointer event handling: https://github.com/cubiq/iscroll/issues/1100

There was a suggestion in that github issue to temporarily disable pointer event support in the library: https://github.com/cubiq/iscroll/issues/1100#issuecomment-266705317

Please give it a try and let us know.

Alternatively, try adding the style "touch-action:none" in the scrollable div. The core problem seems to be with default "touch-action:auto" which prevents sending "pointermove" events to the div except for the first "pointermove" in a touch sequence.

#25: I managed to change "touch-action:auto" to "touch-action:none" while debugging with Chrome devtools in the element <div id="jqt" ... > and it indeed fixed the scrolling for me.

 Issue 676630  has been merged into this issue.

philipp.minnig@ubs.com: Please confirm that adding "touch-action:none" to scrollable divs fixes your app.

Since we did not hear from ubs.com I believe the problem is solved.
Reassigning to mustaq@ and closing. Please update as you see fit.