Philip Jägenstedt
unread,Dec 9, 2014, 8:23:23 AM12/9/14Sign in to reply to author
Sign in to forward
You do not have permission to delete messages in this group
Sign in to report message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to mnag...@chromium.org, Alexandre Elias, Chris Harrelson, Peter Beverloo, Jeremy Roman, Rick Byers, PhistucK, Max Heinritz, blink-dev, android-w...@chromium.org, Martin Kosiba, Ben Murdoch
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