more bisecting:

52.0.2743.99 - good
52.0.2743.117 - good
53.0.2764.0 - good
53.0.2774.0 - good
53.0.2774.4 - good
53.0.2779.0 - bad
53.0.2785.9 - bad
53.0.2785.10 - bad
53.0.2785.97 - bad
54.0.2840.8 - bad
55.0.2868.3 - bad

The offending commit is edd476ed. https://codereview.chromium.org/2068413002

That happens to be within a breakage from one of my GMS roll attempts (c3199997..9ad7108b). Karma.

At some of the previous revisions I tested, where this issue didn't repro, I saw another issue where initially tapping in the contenteditable would temporarily make the whole area (not just a single tile) blurry. Not sure if that's related.

That's an easy way for me to repro this? That is, do you know how I can build WebView shell? You mentioned that it doesn't repro in Chrome...

Do you do Android? Build and install monochrome_apk and system_webview_shell_apk. On the Android device, go to "Settings" > "Developer options" > "WebView implementation" and make sure it's set to "Chrome Debug" (that's the Monochrome you just installed (Monochrome is Chrome+WebView in a single package)). Then run the "WebView Browser Tester" app (that's the shell).

And the HTML I'm using is attached.

Deleted: test.html 2.7 KB

test.html 2.7 KB View Download

Hey, I have a couple of problems following the steps:
1. It seems that monochrome_apk is not a valid target on my checkout (ninja: error: unknown target 'monochrome_apk', did you mean 'monochrome_paks'?)
2. Settings -> Developer options doesn't have a "WebView implementation" setting. I have L, do I need to flash to M for this?

monochrome requires checking out internal clank repo as well. and "WebView implementation" is new on N

I don't think OS version or how webview is packaged matters here, so just build webview like you normally would for your L device :p

Right, sorry, those instructions were for N. If you're using L or M, and you want to avoid using the internal repo, just build and install system_webview_apk. If the install fails because of different signatures, you might have to manually remove the existing WebView:

$ adb root
$ adb remount
$ adb pull /data/system/packages.xml
(edit out the WebView <package> tag from packages.xml)
$ adb push packages.xml /data/system/packages.xml
$ adb shell 'rm -rf /system/app/WebView*'

I know, Android is annoying. Sorry.

re #8 system_webview_package_name = "com.google.android.webview" is so much easier :p

https://www.chromium.org/developers/how-tos/build-instructions-android-webview#TOC-Test-shell:-system_webview_shell_apk

Ok, I have WebView Browser Tester 56.0.2887.0 running. Is there any specific steps I need to take to get this into a bad state? So far, anywhere I click within the page works as expected (no blurriness, nothing jumping around).

If not, then I'll try a different device. 

Are you using the HTML from #5? I'm not aware of any other conditions.

I can repro on N5 and N6, on M and N, and on lots of different WebView versions, including today's ToT.

Just to make sure it actually has the WebView you built, can you go to "Settings" > "Apps" > "Android System WebView" (might have to hit "Show system" in the upper right menu to make WebView show up) and verify it has "version Developer Build"?

Even better, add some log messages in your code and check for those. $ adb logcat

It is indeed version Developer Build. I'll try on an N5.

So, I still can't reproduce on n5x. From the looks of it, what's happening is that we're checkerboarding high res tiles and then show low res content. I'm honestly not sure why this would be happening. I assume there's nothing special about the device and/or settings? Is there any way to grab a trace from monochrome?

I'm trying to get a trace, but my repro has suddenly become unreliable. Weird. It was 100% reliable over the past few days.

Issue 646262 has been merged into this issue.

Dup-ed bug look exactly like this, but according to that bug, this is reproducible on m52 stable as well.

The selection handle jumping around is also really odd, especially in webview, the selection handle is not drawn by the compositor.

Oooooh I figured it out. This only repros while inspecting the WebView (which I suppose makes this a much less important bug, since it won't happen to regular users). Vlad, can you try that?

Specifically, inspecting with the "screencast" enabled. Trace attached.

Deleted: 2016-10-14-blurry-trace.json.xz 265 KB

2016-10-14-blurry-trace.json.xz 265 KB Download

You also have to have the "Toggle screencast" thingy on to reproduce this. The screencast thing in devtools is implemented by software draws (last time I checked anyway..), so which means this bug only reproduces when software draws (with possibly a different draw viewport and transform) is interleaved with regular hardware draws.

You started fixing this bug over two years ago. Are you still working on it?