any devices above N is reproducible. make sure enable multiprocess webview , set chromium webview as system webview.

Tested the issue in Android. Could not reproduce the issue.

Steps Followed:
1. Multi-process webview enabled
2. Launched Browser
3. Navigated to (www.baidu.com)
4. Navigated to some other website
5. Did not observe such behavior

Chrome versions tested:
61.0.3163.98

OS
Android 7.1.2

Android Devices
7.1.2 Pixel XL Build/N2G48E

@greatxuhl: Could you please provide us a sample screencast of the exact issue you'e facing. That would help us in further triaging of the issue.

Thanks!!

Thank you for your attention!

I override onLoadResource function followed: 

  @Override public void onLoadResource(WebView view, String s) {
    view.loadUrl("javascript: var i = 1；");
  }

I found:

1. Disable multi-process webview, everything goes well

2. enable multi-process webview, inject javascript in onPageFinished function(or other recall in later period of webpage loading), everything goes well, too.

a screen record is attached as followed

Deleted: s.mp4 1.1 MB

	s.mp4 1.1 MB View Download

Thank you for providing more feedback. Adding requester "sandeepkumars@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

Could you try to call WebView.stopLoading() before call view.loadUrl("javascript: var i = 1；")?

I need inject in early period of loading page, the page will stay in white when stopLoading is called.

Thank you for providing more feedback. Adding requester "michaelbai@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

OK, so it sounds like the in-progress navigation is being cancelled here. I'm not sure what the expectation is around loading a javascript: URL and whether that will stop pending navigations or not; multiprocess changes the timing/synchronisation of how some events occur, and so it's possible that the only difference here is the timing, and that it would also do the same in single-process if the timing happened to work out similarly. We should check if there's actually a behaviour change here or just a timing difference.

However, I'm a bit puzzled by "inject in early period of loading page" here: you have no way of knowing how far WebView has gotten with loading the page at the time you call loadUrl the second time because loading is asynchronous (even in single-process mode), so there's no guarantee that it will be injected at any particular time; the page might well have been fully loaded by the time your javascript code is executed in any case. What's your actual use case here? Maybe there's a better way to achieve what you're trying to do in the first place that won't run into this issue?

Cc: torne@chromium.org
Labels:  -Needs-Feedback

Thank you for your attention!

I inject javascript to change webview's css style. 

like that:

void onprogresschanged(WebView w, int newprogress){
   w.loadurl("javascript: XXXXXX");
}

I inject javascript when the progress is 20 or less so that I can change css style during loading period. 

If I inject javascript when the progress is 40 or more(DOM tree seems resolved)，everything goes well expect webview flash white.

You're dealing with an inherently asynchronous process, and so none of your solutions are currently correct in all cases. The only way to be sure that your JS was processed at the right time would be to inject it into the page content before WebView receives it.

Having said that, have you checked whether this reproduces if you call evaluateJavascript, rather than loading a javascript: URL?

Thank you for your attention!

Everything is ok if using evaluateJavascript instead of loadurl. :)

I found that function evaluateJavascript asynchronously evaluates JavaScript in the context of the currently displayed page. But I don't know why multiprocess webview affects the performance of javascript.

Closing as the main issue here has been sufficiently addressed. I believe #18 is the asynchronous behavior we're talking about.