Assigning to boliu@ for triage.

things in aw_contents.cc in that CL

GrantFileSchemeAccesstoChildProcess is the same as  issue 767519  I think

GetEffectivePriority is probably ok. Since webview has API to control importance on a per-webcontents level, there is no need to check child frames.

Everything else has to do with the webview-only code path that hooks up rendering. And that code path is definitely not built to support oopif, and I think subframes will just remain blank. Probably takes a quarter or two to fix it properly.

otoh, webview only recently started supporting a single renderer process across all webcontents. So it's probably a few steps away from having to worry about oopif, and p3 is probably right

For content/browser/android/java/gin_java_bridge_... torne@ says: I'm not sure this is going to be the right behaviour if WebView ever actually enables OOPIF. The current behaviour of the Java bridge is that the objects are accessible from all frames on the page, so applying the message filter specifically to the top frame's RPH doesn't seem like it'll work?

Yes, java bridge needs fixing for oopif.

But java bridge is in content. It just happens chrome doesn't use that feature, but nothing is stopping chrome from using it tomorrow. So probably fixed at higher priority than the rest of the webview stuff. Shouldn't be too difficult

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

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

Given that OOPIFs in WebView are considered doable, I'm removing the Hotlist-Recharge-Cold label to still keep track of this work.