New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 725834 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Last visit > 30 days ago
Closed: Nov 2017
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 3
Type: Task

Blocking:
issue 725019



Sign in to add a comment

Determine whether WebView Support Library will support released versions of WebView

Project Member Reported by gsennton@chromium.org, May 24 2017

Issue description

Moved this discussion from b/38301941 to here (to make it public).

 When implementing the WebView Support library we have the choice to support already-released WebView versions, or only versions which we can change (for example to include a new glue-layer for our convenience).

We should investigate how tricky it is to support some earlier WebView versions (and how much more complex the support library code would become by doing so).

I think there are two parts to this:
1. Investigating the differences between a support library implementation calling into an already-released WebView version, and an implementation calling a new WebView version.
2. Given the WebView-layer we would need to reflect into - determine how big changes we've made to that layer in already-released WebView versions - if we have made lots of changes we might need new shim-code in the support library for each WebView version (which seems tedious).
3. And how much extra testing effort by testing team



Initial thoughts given the discussion in  crbug.com/725031 :

trivially, we can't use AIDL to call into an old WebView APK since that APK won't provide the required AIDL interface.

As for reflection - there are some classes in the WebView APK which we would need to subclass/implement in our WebView Support Library to implement certain app callbacks.
For example, if an app wants to implement a callback in the WebViewClient class, then, for the WebView Support Library to support an already released version of WebView it would have to pass an implementation of AwContentsClient to AwContents. AwContentsClient is not a pure interface, but instead an abstract class. We can use the class java.lang.reflect.Proxy to implement any interfaces in the WebView APK, but not abstract classes (because the implementation class we provide will be a sub-class of java.lang.reflect.Proxy, so it can't sub-class an abstract class as well).
So, to support old WebView versions we'll have to use some library providing support for implementing abstract classes through reflection.
 
Labels: WebView-Support-Lib

Comment 2 by sgu...@chromium.org, Sep 27 2017

Cc: -sgu...@chromium.org
Status: WontFix (was: Assigned)
I don't think it makes any sense to support released versions of WebView atm - WebView has a great update-rate, and supporting old WebView versions would require more testing and using more fragile reflection.

I'm gonna close this as Won't Fix for now. We can reopen in the future if it makes sense.

Sign in to add a comment