Can you provide an application in which we can reproduce this? Either your actual app, or a test app that shows the same bug? This isn't happening in general, so there must be something specific to your situation that triggers it.

On which devices does this occur?

FYI, Chrome *is* the WebView implementation on Android 7 and later, so this isn't an "incompatibility" but is presumably an actual bug in webview 69, and if you had updated the separate webview to 69 on a device that uses that you'd probably have the same issue.

FYI, it seems the app in screenshot is this one:  but I guess we need a school account to test it.

https://play.google.com/store/apps/details?id=dev.diodro.com.diodroapp.v1&hl=en_US

A test app is almost always more helpful anyway, as being able to see the source code lets us spot common mistakes.

jnpepo@, the screenshots showed you are using emulator, what's the emulator version do you have? could you please also try to update your emulator?

After having been doing some tests, I think that what is happening:
I have a class that extends to webview control. Inside invalidate (), is where I call setContentView

public class MyWebView extends WebView {
.
.

    @Override
    public void invalidate() {
        super.invalidate();
	setContentView(this);
    }
.
.
}

however, when a chrome version below 69 is installed, the code goes in invalidate () and the web page is displayed.
With chrome version 69 installed, the code never goes inside invalidate (), does not run setContentView () and logically the web page is not displayed.

The question is why it does not trigger invalidate() Webview control with chrome 69.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

jnpepo@, could you answer the question in comment 3 and comment 5 about the device you are using?

Why are you overriding invalidate that way? If you haven't yet attached the WebView to the view hierarchy there's no guarantee we are going to render anything at all, and so we may not call invalidate. If this was working before it was probably by accident. If you explain what you are actually trying achieve we can probably suggest a better way to do it.