How to deal with the "WebView UI thread" from the WebView support library |
||||
Issue descriptionWebView has its own way of defining its "UI thread" - that seems to be the thread from which we call the WebView ctor: http://cs/android/frameworks/base/core/java/android/webkit/WebView.java?rcl=78252a23d6d38e4b1c938fef3d7b1dc6b7dfbe05&l=2552 private final Looper mWebViewThread = Looper.myLooper(); WebView also has a private method checkThread(), which is used to ensure that WebView methods are being called on the WebView UI thread. In the WebView Support Library we should probably also ensure our method calls are being called on the correct thread. But to do so we need to access either the private mWebViewThread variable, or the private checkThread method from the support library. So we might want to turn one of those into a System-API, and then use reflection to get that variable/method on earlier Android versions. Torne/Bo, IIRC you two are usually involved in discussions on calling WebView from the correct thread, WDYT? Note: it looks like we have two checks here - one in WebView (which will cause a strictmodeviolation when an app uses the wrong thread), and one in WebViewChromium (which just posts the method call to the UI thread instead), so maybe the WebView check is not that important?
,
Dec 18 2017
So the WebView.checkThread() call just ensures the Android-requirement of always calling a single View on the same thread is upheld. Technically I guess this isn't required from the support library since we are not making calls on a View, but it would seem more consistent to run the thread-check in the support library as well.. WDYT?
,
Jan 2 2018
consistency sgtm
,
Jan 2 2018
Yeah, all the things in the support library which are equivalent to the non-static calls on WebView objects should be thread-checked in the same way. Static calls are generally expected to be threadsafe.
,
Jan 19 2018
Update here: we're gonna make WebView.checkThread() public so that it can be used from the support library, and we'll use it for the same methods as WebView.
,
Jan 19 2018
,
Jan 19 2018
,
Jan 19 2018
Toby pointed out that it would be nice to clean up our differing views of 'main threads' in the framework vs. the webview apk, and share as many of the thread checks as possible between the support library glue and the old glue. Right now we are leaning towards publishing WebView.getLooper() as an API to get the thread on which WebView APIs should be called, and then implement WebViewCompat.checkThread() using that Looper from the support library. This would mean the support library wouldn't trigger the strictmode violation for calling webview on the wrong thread, but that's probably no biggie as any apps targeting post-ICS will crash when calling webview on the wrong thread..
,
Feb 15 2018
Marking this as fixed as we are adding WebViewCompat.checkThread() in ag/3614605 |
||||
►
Sign in to add a comment |
||||
Comment 1 by boliu@chromium.org
, Nov 27 2017