Adding an additional set of requirements for intents that significantly affect Android WebView

[Chris Harrelson]

A couple of recent intents (in particular the removal of appcache) on Android WebView hit some snags that are unique to that platform (see that link for more details).

For these reasons, and based on recent experience, I think it's appropriate to add some more checklist items for intents that have WebView risk. The proposed text below that would go under the Interoperability and Compatibility Risks section.

Does this intent have the potential to significantly impact Android WebView-based applications? (See here for more information on why changes to this platform carry higher risk.) If so:

* Please explain what you've done (e.g. outreach to app developers, data analysis) to ensure smooth rollout on Android WebView.

* Please affirm that  you've followed the following best practices:

  1. Use a finch-based killswitch in case of compat issues

  2. Reach out to android-webview-dev for advice and feedback

Thoughts?

Chris

[Mike Taylor]

Hi Chris,

I think it makes sense. Perhaps it could be reworded such that we move the best practices part into the webview-changes doc (and add the outreach + analysis bits), so it takes up less space. Maybe:

Does this intent have the potential to significantly impact Android WebView-based applications? (See here for more information on why changes to this platform carry higher risk, and for best practices.) If so:

* Please explain what you've done (i.e. from the list of linked best practices) to ensure smooth rollout on Android WebView.

thanks,

Mike

[Manuel Rego Casasnovas]

On 13/12/2021 17:31, Mike Taylor wrote:
> Hi Chris,
>
> On 12/8/21 5:43 PM, Chris Harrelson wrote:
>> A couple of recent intents (in particular the removal of appcache) on
>> Android WebView hit some snags that are unique to that platform

>> <https://new.chromium.org/developers/webview-changes/> (see that link

>> for more details).
>>
>> For these reasons, and based on recent experience, I think it's
>> appropriate to add some more checklist items for intents that have
>> WebView risk. The proposed text below that would go under

>> the *Interoperability and Compatibility Risks* section.
>>
>> /Does this intent have the potential to significantly impact Android
>> WebView-based applications? (See here
>> <https://new.chromium.org/developers/webview-changes/> for more
>> information on why changes to this platform carry higher risk.) If so:/
>> /* Please explain what you've done (e.g. outreach to app developers,
>> data analysis) to ensure smooth rollout on Android WebView./
>> /* Please affirm that  you've followed the following best practices:/
>> /  1. Use a finch-based killswitch in case of compat issues/
>> /  2. Reach out to android-webview-dev
>> <https://groups.google.com/a/chromium.org/g/android-webview-dev> for
>> advice and feedback/

>
> I think it makes sense. Perhaps it could be reworded such that we move
> the best practices part into the webview-changes doc (and add the
> outreach + analysis bits), so it takes up less space. Maybe:
>

> /Does this intent have the potential to significantly impact Android
> WebView-based applications? (See here
> <https://new.chromium.org/developers/webview-changes/> for more

> information on why changes to this platform carry higher risk, and for

> best practices.) If so:/
> /* Please explain what you've done (i.e. from the list of linked best
> practices) to ensure smooth rollout on Android WebView./

I'm afraid this question might be hard to answer for a lot of people.

I'm wondering if we have a kind of bigger list of examples of things
that are fine and things that are not. Or categories of things that are
totally fine, or that should be checked twice.

Also we should provide a way to ask for help on this, like the original
text from Chris was doing. Anyway I'm wondering if it'd be ok to ask for
every single intent at android-webview-dev? Or can we help people to
avoid doing that?

Cheers,
Rego

[Yoav Weiss]

I share Rego's concerns about this being a question that most Chromium devs won't be able to answer.

We could reduce the "surface" by only raising that question in cases of removals or behavior changes (and not in case of shipping new features).

Otherwise, it seems that the risks for WebView are similar to the risks elsewhere, only amplified.

With that in mind, maybe the change we want is:

• Always include a feature flag for any removals or changes, that can enable us to disable it if we encounter issues (through Finch in case of Chrome. Other Chromiums have similar mechanisms)
• In case of removal or behavior change, loop in webview-dev and let them make the call of a certain change being a particularly high risk for them. For Enterprises, we do that manually. I wonder if the same would work for WebView.

WDYT?

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/f6d2b282-b890-20e5-2b45-0094f9ff7a95%40igalia.com.

[Mike Taylor]

On 12/14/21 3:05 AM, Yoav Weiss wrote:

I share Rego's concerns about this being a question that most Chromium devs won't be able to answer.

We could reduce the "surface" by only raising that question in cases of removals or behavior changes (and not in case of shipping new features).

Otherwise, it seems that the risks for WebView are similar to the risks elsewhere, only amplified.

I had assumed this was the proposal - https://new.chromium.org/developers/webview-changes/ is largely about deprecations and changing behavior of APIs (+ a bit about large architecture changes), but I can see how that's not obvious on re-read (and not sure if that was Chris' intent).

With that in mind, maybe the change we want is:

• Always include a feature flag for any removals or changes, that can enable us to disable it if we encounter issues (through Finch in case of Chrome. Other Chromiums have similar mechanisms)
• In case of removal or behavior change, loop in webview-dev and let them make the call of a certain change being a particularly high risk for them. For Enterprises, we do that manually. I wonder if the same would work for WebView.

WDYT?

That sounds fine to me, but maybe we should ask the android-webview-dev folks for their input (assuming this thread isn't the outcome of such a discussion already).

A questionnaire and review bit in the Chrome launch process is another option, but maybe a heavy handed / super high bandwidth one.

[Chris Harrelson]

On Tue, Dec 14, 2021 at 6:40 AM Mike Taylor <mike...@chromium.org> wrote:

On 12/14/21 3:05 AM, Yoav Weiss wrote:

I share Rego's concerns about this being a question that most Chromium devs won't be able to answer.

We could reduce the "surface" by only raising that question in cases of removals or behavior changes (and not in case of shipping new features).

Otherwise, it seems that the risks for WebView are similar to the risks elsewhere, only amplified.

I had assumed this was the proposal - https://new.chromium.org/developers/webview-changes/ is largely about deprecations and changing behavior of APIs (+ a bit about large architecture changes), but I can see how that's not obvious on re-read (and not sure if that was Chris' intent).

My intent was indeed to restrict it to deprecations, changing behavior, or other risky architectural changes. Adjusted text for this point as well as the "what is high risk" below, bolding of new things:

"(This section generally does not apply when shipping new APIs, just changes of behavior for existing APIs.)

Does this intent have potentially high risk for Android WebView-based applications? (See here for more a definition of "potentially high risk", information on why changes to this platform carry higher risk, and general rules of thumb for which changes have higher or lower risk.) If so:

* Please explain what you've done (e.g. outreach to app developers, data analysis) to ensure smooth rollout on Android WebView.

* Please affirm that  you've followed the following best practices:

  1. Use a finch-based killswitch in case of compat issues

  2. Reach out to android-webview-dev for advice and feedback on the risk level"

With that in mind, maybe the change we want is:

• Always include a feature flag for any removals or changes, that can enable us to disable it if we encounter issues (through Finch in case of Chrome. Other Chromiums have similar mechanisms)
• In case of removal or behavior change, loop in webview-dev and let them make the call of a certain change being a particularly high risk for them. For Enterprises, we do that manually. I wonder if the same would work for WebView.

WDYT?

That sounds fine to me, but maybe we should ask the android-webview-dev folks for their input (assuming this thread isn't the outcome of such a discussion already).

Unfortunately I don't think the android-webview-dev group will have a much better idea for gray area/ non-risky situations than the rest of us.

There is already a paragraph at the webview-changes page that attempts to address what "might be high-risk", and therefore triggers the proposed new policy. Quoted:

"Removals of JavaScript APIs might be high-risk, because code that calls the API will start throwing an exception. Similarly, big architectural changes risk changing unspecified timing of callbacks which apps might inadvertently depend on. On the other hand, changing behavior of(or removing) a CSS property that may result in only cosmetic changes has lower risk for sites that depend on it."

I edited the paragraph to make it more formulaic around the concept of "potentially high risk" in this code review.

[Chris Harrelson]

Friendly ping on this thread. WDYT of this new text?

[Johnny Stenback]

FWIW (i.e. I'm not an API owner) I think the proposed text would be a great addition to the current process and am in favor of making this change.

- jstenback (he/him)

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CA%2BN6QZvHZ06J7c4XtPy8aajAazpq%3Dy_pQLu8xXA%3Df0nwsDsDjg%40mail.gmail.com.

[Chris Harrelson]

I brought up this proposal at the API owners meeting today. The feedback I got was:

* The question is still not actionable enough for the majority of intent owners

* The requirement may confuse or overly burden proposals

In response to that, how about this adjusted text that weakens the requirements substantially? The main changes are in bold, and are basically "use a feature flag killswitch and ask for advice if you're not sure".

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications? (See here for more a definition of "potentially high risk", information on why changes to this platform carry higher risk, and general rules of thumb for which changes have higher or lower risk) If so:
* Please use a base::Feature killswitch that can be flipped off in case of compat issues

* Consider reaching out to android-w...@chromium.org for advice

* If you're not sure, just put "not sure" as the answer here and the API owners can help during the intent-to-ship

On Mon, Jan 3, 2022 at 1:01 PM Chris Harrelson <chri...@chromium.org> wrote:

On Tue, Dec 14, 2021 at 6:40 AM Mike Taylor <mike...@chromium.org> wrote:

On 12/14/21 3:05 AM, Yoav Weiss wrote:

I share Rego's concerns about this being a question that most Chromium devs won't be able to answer.

We could reduce the "surface" by only raising that question in cases of removals or behavior changes (and not in case of shipping new features).

Otherwise, it seems that the risks for WebView are similar to the risks elsewhere, only amplified.

I had assumed this was the proposal - https://new.chromium.org/developers/webview-changes/ is largely about deprecations and changing behavior of APIs (+ a bit about large architecture changes), but I can see how that's not obvious on re-read (and not sure if that was Chris' intent).

My intent was indeed to restrict it to deprecations, changing behavior, or other risky architectural changes. Adjusted text for this point as well as the "what is high risk" below, bolding of new things:

"(This section generally does not apply when shipping new APIs, just changes of behavior for existing APIs.)

Does this intent have potentially high risk for Android WebView-based applications? (See here for more a definition of "potentially high risk", information on why changes to this platform carry higher risk, and general rules of thumb for which changes have higher or lower risk.) If so:
* Please explain what you've done (e.g. outreach to app developers, data analysis) to ensure smooth rollout on Android WebView.
* Please affirm that  you've followed the following best practices:
  1. Use a finch-based killswitch in case of compat issues
  2. Reach out to android-webview-dev for advice and feedback on the risk level"

I  that in mind, maybe the change we want is:

[Daniel Bratell]

I think that is reasonable!

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CA%2BN6QZt99Oj%2BbLsz7mp-0fJBK68X6aBX%3D660vU%2BMKp8Sftzxyg%40mail.gmail.com.

[Yoav Weiss]

+1 from me as well!

[Manuel Rego Casasnovas]

LGTM too.

On 24/02/2022 08:28, 'Yoav Weiss' via blink-api-owners-discuss wrote:
> +1 from me as well!
>
> On Thu, Feb 24, 2022 at 7:48 AM Daniel Bratell <bra...@sarasas.se
> <mailto:bra...@sarasas.se>> wrote:
>
> I think that is reasonable!
>
> /Daniel
>
> On 2022-02-23 22:44, Chris Harrelson wrote:
>> I brought up this proposal at the API owners meeting today. The
>> feedback I got was:
>> * The question is still not actionable enough for the majority of
>> intent owners
>> * The requirement may confuse or overly burden proposals
>>
>> In response to that, how about this adjusted text that weakens the
>> requirements substantially? The main changes are in bold, and are
>> basically "use a feature flag killswitch and ask for advice if
>> you're not sure".
>>

>> /Does this intent *deprecate or change behavior of existing APIs*,

>> such that it has potentially high risk for Android WebView-based
>> applications? (See here

>> <https://new.chromium.org/developers/webview-changes/> for more a
>> definition of "potentially high risk",**information on why changes

>> to this platform carry higher risk, and general rules of thumb for
>> which changes have higher or lower risk) If so:
>> * Please use a base::Feature killswitch that can be flipped off in

>> case of compat issues/
>> /* *Consider* reaching out to android-w...@chromium.org
>> <mailto:android-w...@chromium.org> for advice/
>> */* If you're not sure, just put "not sure" as the answer here and
>> the API owners can help during the intent-to-ship/*

>>
>> On Mon, Jan 3, 2022 at 1:01 PM Chris Harrelson
>> <chri...@chromium.org <mailto:chri...@chromium.org>> wrote:
>>
>>
>>
>> On Tue, Dec 14, 2021 at 6:40 AM Mike Taylor
>> <mike...@chromium.org <mailto:mike...@chromium.org>> wrote:
>>
>> On 12/14/21 3:05 AM, Yoav Weiss wrote:
>>> I share Rego's concerns about this being a question that
>>> most Chromium devs won't be able to answer.
>>> We could reduce the "surface" by only raising that
>>> question in cases of removals or behavior changes (and
>>> not in case of shipping new features).
>>> Otherwise, it seems that the risks for WebView are
>>> similar to the risks elsewhere, only amplified.
>>
>> I had assumed this was the proposal -
>> https://new.chromium.org/developers/webview-changes/
>> <https://new.chromium.org/developers/webview-changes/> is
>> largely about deprecations and changing behavior of APIs
>> (+ a bit about large architecture changes), but I can see
>> how that's not obvious on re-read (and not sure if that
>> was Chris' intent).
>>
>> My intent was indeed to restrict it to deprecations,
>> changing behavior, or other risky architectural changes.
>> Adjusted text for this point as well as the "what is high
>> risk" below, bolding of new things:
>>

>> "*(This section generally does not apply when shipping new
>> APIs, just changes of behavior for existing APIs.)*
>> Does this intent have *potentially high risk* for Android
>> WebView-based applications? (*See here
>> <https://new.chromium.org/developers/webview-changes/> for
>> more a definition of "potentially high risk", *information on

>> why changes to this platform carry higher risk, and general
>> rules of thumb for which changes have higher or lower risk.)
>> If so:
>> * Please explain what you've done (e.g. outreach to app
>> developers, data analysis) to ensure smooth rollout on Android
>> WebView.
>> * Please affirm that  you've followed the following best
>> practices:
>>   1. Use a finch-based killswitch in case of compat issues
>>   2. Reach out to android-webview-dev for advice and feedback

>> *on the risk level*"

>>
>>> I  that in mind, maybe the change we want is:
>>>

>>> * Always include a feature flag for any removals or

>>> changes, that can enable us to disable it if we
>>> encounter issues (through Finch in case of Chrome.
>>> Other Chromiums have similar mechanisms)

>>> * In case of removal or behavior change, loop in

>>> webview-dev and let them make the call of a certain
>>> change being a particularly high risk for them. For
>>> Enterprises, we do that manually. I wonder if the
>>> same would work for WebView.
>>>
>>> WDYT?
>>
>> That sounds fine to me, but maybe we should ask the
>> android-webview-dev folks for their input (assuming this
>> thread isn't the outcome of such a discussion already).
>>
>> Unfortunately I don't think the android-webview-dev group will
>> have a much better idea for gray area/ non-risky situations
>> than the rest of us.
>>
>> There is already a paragraph at the webview-changes page that
>> attempts to address what "might be high-risk", and therefore
>> triggers the proposed new policy. Quoted:
>>
>> "Removals of JavaScript APIs might be high-risk, because code
>> that calls the API will start throwing an exception.
>> Similarly, big architectural changes risk changing unspecified
>> timing of callbacks which apps might inadvertently depend on.
>> On the other hand, changing behavior of(or removing) a CSS
>> property that may result in only cosmetic changes has lower
>> risk for sites that depend on it."
>>
>> I edited the paragraph to make it more formulaic around the
>> concept of "potentially high risk" in this code review

>> <https://chromium-review.googlesource.com/c/website/+/3365371>.

>>> <mailto:blink-api-owners-discuss%2Bunsu...@chromium.org>.

>>> To view this discussion on the web visit
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/f6d2b282-b890-20e5-2b45-0094f9ff7a95%40igalia.com

>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/f6d2b282-b890-20e5-2b45-0094f9ff7a95%40igalia.com>.

>>>
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "blink-api-owners-discuss" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to blink-api-owners-d...@chromium.org

>> <mailto:blink-api-owners-d...@chromium.org>.

>> To view this discussion on the web visit

>> https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CA%2BN6QZt99Oj%2BbLsz7mp-0fJBK68X6aBX%3D660vU%2BMKp8Sftzxyg%40mail.gmail.com
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CA%2BN6QZt99Oj%2BbLsz7mp-0fJBK68X6aBX%3D660vU%2BMKp8Sftzxyg%40mail.gmail.com?utm_medium=email&utm_source=footer>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "blink-api-owners-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to blink-api-owners-d...@chromium.org

> <mailto:blink-api-owners-d...@chromium.org>.

> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAL5BFfWuX3bfj1ycz%2BjG7GgwTMvope6JghxKCy5rCbF7c1h4Yw%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAL5BFfWuX3bfj1ycz%2BjG7GgwTMvope6JghxKCy5rCbF7c1h4Yw%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Mike Taylor]

+1

[Chris Harrelson]

Hearing no objections and many LGTMs, I'm going to move forward with this proposal.

[Chris Harrelson]

https://github.com/GoogleChrome/chromium-dashboard/issues/1775