Adding Android WebView in intent to implement/ship

[Alexandre Elias]

As I mentioned in my BlinkOn talk about Android WebView, that configuration is in some sense the "secret 6th Blink platform" different in some fundamental ways from Chrome for Android.  It's also an officially supported configuration of Chromium/Blink, with the goal of having web platform parity as much as possible, so I think it would make sense to call it out explicitly in the intent to implement/ship templates, on the line "Will this feature be supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?"

As some examples of the sort of web platform feature that may require extra work to implement on WebView, some examples of previous web platform features with significant WebView implications were:

- WebGL (different GL pipeline)

- <meta viewport> tag (due to interactions with Android View layout)

- Page Visibility API (because visibility transitions are made synchronously on another 

thread)

- enterFullscreen API (because WebView does not control the entire screen)

- Service Worker (because WebView has different assumptions about process lifetime)

Most of these features predated the Chromium WebView, but moving forward I'd like us to consider the WebView case explicitly, particularly at the "intent to implement" stage.  If in doubt, ask android-webview-dev@ about whether your new feature might require extra work for WebView compatibility.

If there are no objections, could someone with the right permissions make that edit to the Intent template?

--
Alex

[Chris Harrelson]

This sounds proposal sounds great to me.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[PhistucK]

Makes total sense. :)

☆PhistucK

[Rick Byers]

I agree this is very important.  In general I feel we should be thinking about and investing more in WebView scenarios.  It's the primary tool we have for enabling developers to make a series of small decisions to leverage the web platform on mobile, rather than being forced to make one big up-front decision (which all too often doesn't have the outcome we'd prefer).

I've made suggested edits to the template, but someone (perhaps only meh@?) will need to approve them.

Rick

[Jeremy Roman]

Does Chromecast count as another platform, too? I'm not familiar
enough with how it fits into the picture.

[Alexandre Elias]

Chromecast is effectively another platform, but I'm not sure that it's a major goal of that project to support 100% of the web platform (my understanding is that it mostly displays HTML written specifically for it).  Chromecast also hasn't fully upstreamed their fork yet so Blink developers without special access would currently be unable to test their new feature against it.  So at least for now, I think we shouldn't add Chromecast to the template, although we can reconsider in the future if someone from that team asks for it.

--
Alex

[Peter Beverloo]

Could you perhaps set up some guidelines on the wiki, explaining things to keep in mind when thinking about implementing an API for WebView?

The primary, more common pitfalls I'm thinking about are permission requests, required Android permissions and when it's a good idea to expose something as an API on the Java WebView. It's also useful to point out that WebView is build on top of the content/ API, and doesn't use any of components/ or chrome/.

There's also larger unresolved questions around how we expect Service Workers to work, as well as the APIs built on top of it -- Push API, notifications, background sync, and so on. These will still have to be discussed on a case-by-case basis, so perhaps pointing to android-w...@chromium.org is worthwhile as well.

Admittedly, many of these issues are more relevant to the Chromium part of the implementation, but implementors will undoubtedly run in to them.

Thanks,

Peter

--
You received this message because you are subscribed to the Google Groups "android-webview-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-webview...@chromium.org.
To post to this group, send email to android-w...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/android-webview-dev/CADeTeo5Q1cFW%2BVU1-%2BOg2-Ocm9f-BO9_x6WXiOoky_OQaGCBQQ%40mail.gmail.com.

[Mikhail Naganov]

On Thu, Nov 13, 2014 at 12:13 PM, Peter Beverloo <pe...@chromium.org> wrote:

Could you perhaps set up some guidelines on the wiki, explaining things to keep in mind when thinking about implementing an API for WebView?

Single-process mode is one of the main factors to take into account, and also things like application lifecycle, WebView control size, its position in the view hierarchy, are out of our control.

 

The primary, more common pitfalls I'm thinking about are permission requests, required Android permissions and when it's a good idea to expose something as an API on the Java WebView. It's also useful to point out that WebView is build on top of the content/ API, and doesn't use any of components/ or chrome/.

We do use components/ in WebView. I think, a lot of the code was actually componentized in order to be usable from WebView. See https://code.google.com/p/chromium/codesearch#chromium/src/android_webview/android_webview.gyp:

        '../components/components.gyp:auto_login_parser',

        '../components/components.gyp:autofill_content_renderer',

        '../components/components.gyp:cdm_browser',

        '../components/components.gyp:cdm_renderer',

        '../components/components.gyp:data_reduction_proxy_core_browser',

        '../components/components.gyp:navigation_interception',

        '../components/components.gyp:visitedlink_browser',

        '../components/components.gyp:visitedlink_renderer',

        '../components/components.gyp:web_contents_delegate_android',

[Chris Harrelson]

I've finally gotten access to the Intent templates and updated them to account for Android WebView.

I went through the intents that happened since Nov 13, and didn't see any Intents to Implement, Deprecate or Ship that appear to have an architectural incompatibility with Android WebView (if anyone sees one please speak up).

However, there has been the usual guessing game about whether it's ok to deprecate or remove an undesired feature, based on what limited data we have about popularity. Is there any useful data about WebView in this regard?

Also, Mikhail/Alex, did you get a chance to make on the chromium.org site outlining hints for implementing to be WebView-compatible? If not let's add one.

Chris

[Alexandre Elias]

On Mon, Dec 8, 2014 at 5:31 PM, Chris Harrelson <chri...@chromium.org> wrote:

I've finally gotten access to the Intent templates and updated them to account for Android WebView.

I went through the intents that happened since Nov 13, and didn't see any Intents to Implement, Deprecate or Ship that appear to have an architectural incompatibility with Android WebView (if anyone sees one please speak up).

However, there has been the usual guessing game about whether it's ok to deprecate or remove an undesired feature, based on what limited data we have about popularity. Is there any useful data about WebView in this regard?

It is conceivable that WebView-specific HTML uses a nonstandard feature in a way that doesn't happen on the open web, particularly as WebView apps can assume they're running on WebKit/Blink.  Unfortunately, we don't have a good way to gather data on this HTML.  For what it's worth, in the past, the only web platform feature I recall that had WebView-specific compatibility issues was the <meta viewport> tag, because the classic WebView had an quirky implementation of it not shared by any other WebKit ports.  Every other WebView-breaking change also was observed to cause problems in Chrome on the open web too, and hopefully that will continue to be the case.

Some good news is that WebView has a better versioning story for deprecation: app developers specify a targetSdkVersion number, which represents the latest Android release they've tested their app on.  We can disable a deprecated feature if the targetSdkVersion is high enough, and enable it via a quirks mode on lower versions.  So we have more flexibility if a WebView-specific problem does arise.

 

Also, Mikhail/Alex, did you get a chance to make on the chromium.org site outlining hints for implementing to be WebView-compatible? If not let's add one.

Hmm, the details will vary so much depending on the exact kind of feature being implemented that it's hard to provide much specific advice.  The most important thing is for Chromium/Blink contributors to have a basic idea of the WebView's differences with Chrome, so they can identify when there might be some difficulty, then contact android-webview-dev@ when needed.  We just should probably just a create a page linking to all the publicly available docs about it.

[Chris Harrelson]

On Mon, Dec 8, 2014 at 6:21 PM, Alexandre Elias <ael...@google.com> wrote:

On Mon, Dec 8, 2014 at 5:31 PM, Chris Harrelson <chri...@chromium.org> wrote:

I've finally gotten access to the Intent templates and updated them to account for Android WebView.

I went through the intents that happened since Nov 13, and didn't see any Intents to Implement, Deprecate or Ship that appear to have an architectural incompatibility with Android WebView (if anyone sees one please speak up).

However, there has been the usual guessing game about whether it's ok to deprecate or remove an undesired feature, based on what limited data we have about popularity. Is there any useful data about WebView in this regard?

It is conceivable that WebView-specific HTML uses a nonstandard feature in a way that doesn't happen on the open web, particularly as WebView apps can assume they're running on WebKit/Blink.  Unfortunately, we don't have a good way to gather data on this HTML.  For what it's worth, in the past, the only web platform feature I recall that had WebView-specific compatibility issues was the <meta viewport> tag, because the classic WebView had an quirky implementation of it not shared by any other WebKit ports.  Every other WebView-breaking change also was observed to cause problems in Chrome on the open web too, and hopefully that will continue to be the case.

Some good news is that WebView has a better versioning story for deprecation: app developers specify a targetSdkVersion number, which represents the latest Android release they've tested their app on.  We can disable a deprecated feature if the targetSdkVersion is high enough, and enable it via a quirks mode on lower versions.  So we have more flexibility if a WebView-specific problem does arise.

Good to know.

 

 

Also, Mikhail/Alex, did you get a chance to make on the chromium.org site outlining hints for implementing to be WebView-compatible? If not let's add one.

Hmm, the details will vary so much depending on the exact kind of feature being implemented that it's hard to provide much specific advice.  The most important thing is for Chromium/Blink contributors to have a basic idea of the WebView's differences with Chrome, so they can identify when there might be some difficulty, then contact android-webview-dev@ when needed.  We just should probably just a create a page linking to all the publicly available docs about it.

I've added a skeleton page with a link to your BlinkOn presentation and the suggested email address:

https://sites.google.com/a/chromium.org/dev/androidwebview 

[Mikhail Naganov]

Thank you very much, Chris!

[Philip Jägenstedt]

On Tue, Dec 9, 2014 at 3:21 AM, 'Alexandre Elias' via blink-dev
<blin...@chromium.org> wrote:

> Some good news is that WebView has a better versioning story for
> deprecation: app developers specify a targetSdkVersion number, which
> represents the latest Android release they've tested their app on. We can
> disable a deprecated feature if the targetSdkVersion is high enough, and
> enable it via a quirks mode on lower versions. So we have more flexibility
> if a WebView-specific problem does arise.

In practice, does this mean adding the feature to
RuntimeEnabledFeatures and enabling it only for WebView for a few
years until the feature has made it through the Android cycle of
deprecation and removal? That does sound hopeful, if it should even be
required. However, having something permanently enabled only on
Android WebView sounds painful, if eventual removal on Android is
impossible it seems almost better to try standardization and enabling
it everywhere and forever.

Philip

[Mikhail Naganov]

Hello Philip,

I would like to provide some clarifications:

> In practice, does this mean adding the feature to RuntimeEnabledFeatures and enabling it only for WebView for a few years until the feature has made it through the Android cycle of deprecation and removal? 

I think, you are confusing things here. The Android cycle of deprecation usually applies to Java APIs exposed by WebView, e.g. for enabling / disabling JavaScript, localstorage APIs, zooming etc. Web Platform APIs are more flexible, since they are only exposed to JavaScript code. Although, we definitely don't want to break apps that rely on there APIs with a WebView update.

In practice, this means that we tend to enable new Web Platform APIs on WebView once they are mature enough on other platforms, and we have provided required support in the WebView layer. See the feature matrix here: https://developer.chrome.com/multidevice/webview/overview#does_the_new_webview_have_feature_parity_with_chrome_for_android_

We didn't have yet any cases of disabling a Web Platform API in WebView.

Should a Web Platform API require a support from the embedder of WebView, this will probably mean that a new Java API will be needed, and for it the usual Android API lifecycle rules apply. An example of such a feature is anything that requires a user confirmation in browsers, e.g. geolocation, storing large amounts of data on the device, running full-screen, etc.

> However, having something permanently enabled only on Android WebView sounds painful, if eventual removal on Android is impossible it seems almost better to try standardization and enabling it everywhere and forever.

We have examples of code that we had to add to Blink in order to support Android apps that were relying on certain non-standard behaviour of pre-KitKat WebViews, e.g. look at PageScaleConstraintsSet::adjustForAndroidWebViewQuirks, or for different quirky settings in https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/frame/Settings.in

They are usually very local, and are covered with tests. Although, we are agree that this puts some additional burden on the developers, so we are hoping to remove them at some point.

[Philip Jägenstedt]

On Tue, Dec 9, 2014 at 2:09 PM, Mikhail Naganov <mnag...@chromium.org> wrote:
> Hello Philip,
>
> I would like to provide some clarifications:
>
>> In practice, does this mean adding the feature to RuntimeEnabledFeatures
>> and enabling it only for WebView for a few years until the feature has made
>> it through the Android cycle of deprecation and removal?
>
> I think, you are confusing things here. The Android cycle of deprecation
> usually applies to Java APIs exposed by WebView, e.g. for enabling /
> disabling JavaScript, localstorage APIs, zooming etc. Web Platform APIs are
> more flexible, since they are only exposed to JavaScript code. Although, we
> definitely don't want to break apps that rely on there APIs with a WebView
> update.
>
> In practice, this means that we tend to enable new Web Platform APIs on
> WebView once they are mature enough on other platforms, and we have provided
> required support in the WebView layer. See the feature matrix here:
> https://developer.chrome.com/multidevice/webview/overview#does_the_new_webview_have_feature_parity_with_chrome_for_android_
>
> We didn't have yet any cases of disabling a Web Platform API in WebView.
>
> Should a Web Platform API require a support from the embedder of WebView,
> this will probably mean that a new Java API will be needed, and for it the
> usual Android API lifecycle rules apply. An example of such a feature is
> anything that requires a user confirmation in browsers, e.g. geolocation,
> storing large amounts of data on the device, running full-screen, etc.

Thanks for clarifying. I guess we should wait until we have an actual
case where only WebView stands in the way of removing a Web-exposed
API before figuring out how to deal with that.

>> However, having something permanently enabled only on Android WebView
>> sounds painful, if eventual removal on Android is impossible it seems almost
>> better to try standardization and enabling it everywhere and forever.
>
> We have examples of code that we had to add to Blink in order to support
> Android apps that were relying on certain non-standard behaviour of
> pre-KitKat WebViews, e.g. look at
> PageScaleConstraintsSet::adjustForAndroidWebViewQuirks, or for different
> quirky settings in
> https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/frame/Settings.in
>
> They are usually very local, and are covered with tests. Although, we are
> agree that this puts some additional burden on the developers, so we are
> hoping to remove them at some point.

Yeah, I've seen a few of these. Trivial things like
defaultVideoPosterURL don't add much of a burden. I was thinking of a
scenario where we were able to remove, say, Attr's child Text nodes on
all platforms except WebView, in which case we'd still be stuck with
the full complexity of supporting that but with a lot less coverage of
the code, making it easier to break, etc.

Philip