Pavel Zdeněk <pavel.zde...@gmail.com> writes: > Dear mailing list, > > For reasons too complicated to explain here, i would like to have a > result of WebViewClient.shouldInterceptRequest be based on a result of > Javascript call in another WebView instance. As shouldInterceptRequest > is being invoked on a non-Main thread, while > WebView.evaluateJavascript is expected to be called on Main, i > actually tried it. Miracles don't happen: the shouldInterceptRequest > IOThread gets as far as enqueing a main thread task and waiting itself > on a condition. Main thread keeps running after evaluateJavascript > execution, but its ValueCallback never hits. Chrome Inspection of the > "another" WebView instance shows it frozen, expectedly deadlocked on > IOThread somewhere inside WebKit. > > My skimming of the WebKit and Crosswalk sources shows that > shouldInterceptRequest starts its life as an asynchronous IOThread > task, so my question is: how insane it would be to try propagating > that asynchronicity through the JNI interface, so that it won't block > IOThread on return value? > > FYI, the Android PoC is here > https://github.com/pavel-zdenek/android-testbrowser > which works out of the box because i shortcutted the JS eval. It will > deadlock on uncommenting > https://github.com/pavel-zdenek/android-testbrowser/blob/master/app/src/main/java/my/mybrowser/background/ScriptContainer.java#L111 > (and removing the following line)
For posterity: this is also being discussed in the android-webview-dev mailing list: https://groups.google.com/a/chromium.org/d/msg/android-webview-dev/fqCnyU-ejJU/b0pTOM8WGAAJ _______________________________________________ Crosswalk-dev mailing list Crosswalk-dev@lists.crosswalk-project.org https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
