gonna need a repro app, the description by itself isn't really helpful

Have you tried the steps? We have no problems reproducing this with those steps and I imagine you have the possibility to enable some more debugging or similar in WebView to dig a little deeper on that end. If you do have troubles reproducing please let us know what you see.

Of course, we are still trying to isolate it into a test app but would be appreciated if you still look into this a little until then.

I have no idea yet.
Does opera mini have any special code for N only?

I can reproduce the bug but I don't know what's going on:
Chrome://inspect shows that the texts are typed into the field correctly.
Hierarchyviewer shows the same.
Tracing shows the draw and swap happened.

One thing to note is that if you scroll the page afterwards, the texts are shown. 

sbergner@opera.com: any help will be helpful, like providing us a smaller sample app that reproduces the problem.

I also enabled "--enable-skia-benchmarking" and I see that LayerTreeHostImpl got the correct frames.

> Does opera mini have any special code for N only?
Not in version 18

Still trying to create a test app.

One additional thing to note is that if we put a dummy (but drawing) view behind the WebView area the problem is not seen which further indicates it being some invalidation/draw issue.

Also, enabling the "Show GPU view updates" in Developer options shows a lack of updates when comparing the device (not working) vs. emulator (working). In the emulator the WebView area flashes with every cursor blink, something that does not occur on device.

Ok, finally isolated this problem. Turns out that the breaking factor here is if you clear the window background then nothing seem to drive the system to redraw the webview content. Feels like WebView somehow fails to tell the system/windowmgr it needs to redraw as page content changes (animates or text edited or similar). Reproduces with this simple activity:

import android.app.Activity;
import android.os.Bundle;
import android.os.Handler;
import android.view.ViewGroup;
import android.webkit.WebSettings;
import android.webkit.WebView;
import android.webkit.WebViewClient;

public class MainActivity extends Activity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        final WebView wv = new WebView(this);
        setContentView(wv, new ViewGroup.LayoutParams(ViewGroup.LayoutParams.MATCH_PARENT,
                ViewGroup.LayoutParams.MATCH_PARENT));

        // Avoid overdraw according to http://www.curious-creature.com/2012/12/01/android-performance-case-study/
        // CAUSES BUG: With this WebView will fail to update its cursor/edit fields
        getWindow().setBackgroundDrawable(null);

        final WebSettings settings = wv.getSettings();
        settings.setJavaScriptEnabled(true);
        wv.setWebViewClient(new WebViewClient() {
            @Override
            public boolean shouldOverrideUrlLoading(WebView view, String url) {
                return false;
            }
        });
        new Handler().post(new Runnable() {
            @Override
            public void run() {
                wv.loadUrl("http://www.google.com");
            }
        });
    }
}

Possibly the same issue as b/31228366 reported internally:

" On the Nexus 6P, running N, the WebView is blank until the app is put into the background (i.e. pressing the square button). When the app is selected and brought to the foreground, the WebView shows the web page. The developer found that this only happens when the Activity has a null windowBackground. Setting the window background to anything other than null, including transparent, causes the web page to be displayed correctly when the app is first launched. "

Sounds very similar.

yeah.... I think this is the same issue as b/31228366. And it should be a bug in Android N.

#9:
Thank you sbergner@!

Bo/Toby:
Could you take a look on this one?