Intent to Ship: Android OSK resizes visual viewport by default + <meta> opt-out

[David Bokan]

Contact emails

bo...@chromium.org

Explainer

https://github.com/bramus/viewport-resize-behavior/blob/main/explainer.md

Specification

The resize behavior of the virtual keyboard is not specified.

The viewport meta tag is not yet fully specified.

See also https://github.com/w3c/csswg-drafts/issues/7767.

Summary

This intent:

• Changes the Android virtual keyboard such that it resizes the visual viewport only, rather than the current behavior of resizing the initial containing block (ICB) and layout viewport (LVP).
• Ships support for a new meta-viewport key interactive-widgets which can be used to opt-out of the above change, and instead retain the old behavior.
  
  Example: <meta name=”viewport” content=”interactive-widgets=resize-layout”>

Motivation
Browsers do not currently agree on how the virtual keyboard should interact with the viewport:

• Chrome for Android and Firefox for Android both resize the initial containing block and  layout viewport.

• Chrome for ChromeOS and Windows; and Safari/iOS both resize the visual viewport only.

This discrepancy is a source of frustration for authors [1] [2] [3] [4]. While both approaches have valid use-cases, we believe that resizing the visual viewport is the best default, as it avoids any layout-jank from opening the keyboard, and in general interferes with the page as little as possible.

Other vendors also have long-standing issues in this area: https://bugzilla.mozilla.org/show_bug.cgi?id=1007286

This intent improves interop for mobile viewports, a priority investigation area for Interop 2022. Mobile viewports (especially the meta tag) are unfortunately not well specified, and we plan to work on resolving CSSWG issue 7767 in parallel with this intent. In the meantime we plan to add this feature to the Compat spec.

Blink component

Blink>Scroll

TAG review

N/A

TAG review status

Not applicable

Risks

Interoperability and Compatibility

The main risk with this change is web apps which critically depend on the current LVP-resize behavior, e.g. a chat app with a message box fixed above the keyboard.

Those use-cases would no longer be possible with the default behavior, and it was exactly this concern that stopped the previous attempt to ship this behavior at LGTM2.

What makes this intent different:

• The VirtualKeyboard API now exists, which exposes the geometry of the keyboard as CSS-reachable environment variables allowing app full control over keyboard behavior.

• For an easier fix, a new <meta> opt-out has been added which can be used to maintain the current LVP-resize behavior. This is a trivial fix for any affected web app.

As there is no good way to detect the problematic cases with a use-counter / HTTP Archive query, we must instead rely on developer outreach to inform this change. That outreach will reference this intent, and therefore the results of that will be provided in a follow-up e-mail.

We expect this change to be a significant win for interop.

Signals:

Gecko: No response yet[standards position] (Some non-official positive signals from Mozilla engineers from discussions at TPAC and in 7767 that Firefox could make this change)

WebKit: No response yet [standards position]. The change to Chromium’s default behavior would now align with WebKit behavior..

Web developers: See “author frustration” links earlier in this e-mail.

Other signals: N/A

WebView application risks

There is no intended behavior change for Android WebView. The Android app is responsible for sizing the WebView and can implement either mode via windowSoftInputMode.

Debuggability

N/A - There's no DevTools functionality directly related to the virtual keyboard.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

This change affects only Android, bringing it in alignment with Chrome's virtual keyboard behavior on ChromeOS and Windows.

Is this feature fully tested by web-platform-tests?

No. It is currently impossible to test the virtual keyboard as a WPT.

Flag name

OSKResizesVisualViewport

Requires code in //chrome?

Yes - Interaction between web contents container and on-screen keyboard is implemented in the //chrome layer.

Tracking bug

1353728

404315

Estimated milestones

M108

Note: This change does carry relatively significant compat risk which is difficult to measure. As such, we’re planning a careful approach. The feature will have a chrome://flag and enterprise policy to allow opting-out. We plan to widely share this change via DevRel channels and closely monitor feedback and bug reports prior to hitting stable to gauge if a rollback is needed.

Anticipated spec changes

• The keyboard behavior is not governed by any spec.

• The “viewport” <meta> is also not governed by any spec at the time of writing, although there is a recent ambition to change that.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6145225857171456

[Philip Jägenstedt]

I think this plan makes sense, but the lack of a spec makes it unusual.

Can you say more about how this will eventually be spec'd, and who is signed up to push that work to completion?

Since Firefox Android would also need to change to get full interop, a stronger statement from Mozilla would be really helpful. Would they be happy to ship this if it turns out to be web compatible in Chrome?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/32f2f64f-c49c-4208-b9b9-bd480e64d523n%40chromium.org.

[Chris Harrelson]

(API owner hat off for this intent, I'm one of the people working on this feature change)

On Tue, Sep 27, 2022 at 1:32 AM Philip Jägenstedt <foo...@chromium.org> wrote:

I think this plan makes sense, but the lack of a spec makes it unusual.

Can you say more about how this will eventually be spec'd, and who is signed up to push that work to completion?

The feature will be documented in the Compat spec for now, and once there is spec text for CSS viewport we'll add it there. The <meta> tag is not specified at all at present..

 

Since Firefox Android would also need to change to get full interop, a stronger statement from Mozilla would be really helpful. Would they be happy to ship this if it turns out to be web compatible in Chrome?

In a discussion with Emilio (cc'd) at TPAC, he informally agreed it's probably fine to switch Firefox Android to match in a similar time frame.

(Emilio, please let me know if I've misquoted in any way. :) )

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYeaihvGtV%3D0NuqdPGEuMP664dUEh2%3DO83WYwSCmHOvC%3DA%40mail.gmail.com.

[Philip Jägenstedt]

On Tue, Sep 27, 2022 at 7:07 PM Chris Harrelson <chri...@google.com> wrote:

(API owner hat off for this intent, I'm one of the people working on this feature change)

On Tue, Sep 27, 2022 at 1:32 AM Philip Jägenstedt <foo...@chromium.org> wrote:

I think this plan makes sense, but the lack of a spec makes it unusual.

Can you say more about how this will eventually be spec'd, and who is signed up to push that work to completion?

The feature will be documented in the Compat spec for now, and once there is spec text for CSS viewport we'll add it there. The <meta> tag is not specified at all at present..

Ah yes, it was linked in the text. Will someone send a pull request for https://github.com/whatwg/compat? Normally we'd block shipping on the spec change being made, and since the Compat spec exists and it sounds like there's multi-vendor support, I think we can stick to that here too, right?

Since Firefox Android would also need to change to get full interop, a stronger statement from Mozilla would be really helpful. Would they be happy to ship this if it turns out to be web compatible in Chrome?

In a discussion with Emilio (cc'd) at TPAC, he informally agreed it's probably fine to switch Firefox Android to match in a similar time frame.

(Emilio, please let me know if I've misquoted in any way. :) )

Sounds good! If we do a compat spec PR, support on that would do the trick. 

[David Bokan]

Sure, I'll start on a PR.

Taking another look, there does seem to be some basic parsing of the meta in CSS Viewport. It's still a fairly early-stage spec but I wonder if it'd make more sense to just add the `interactive-widgets` keyword there rather than bouncing it between the two specs? I could also help flesh out the meta processing model more generally there.

[Rune Lillesveen]

On Wed, Sep 28, 2022 at 3:38 PM David Bokan <bo...@chromium.org> wrote:

Sure, I'll start on a PR.

Taking another look, there does seem to be some basic parsing of the meta in CSS Viewport. It's still a fairly early-stage spec but I wonder if it'd make more sense to just add the `interactive-widgets` keyword there rather than bouncing it between the two specs? I could also help flesh out the meta processing model more generally there.

That parsing algorithm is something I wrote back in 2010 based on testing Safari on an iPod Touch, not looking at the WebKit source code. That part should just be ditched.

On Wed, Sep 28, 2022 at 2:26 AM Philip Jägenstedt <foo...@chromium.org> wrote:

On Tue, Sep 27, 2022 at 7:07 PM Chris Harrelson <chri...@google.com> wrote:

(API owner hat off for this intent, I'm one of the people working on this feature change)

On Tue, Sep 27, 2022 at 1:32 AM Philip Jägenstedt <foo...@chromium.org> wrote:

I think this plan makes sense, but the lack of a spec makes it unusual.

Can you say more about how this will eventually be spec'd, and who is signed up to push that work to completion?

The feature will be documented in the Compat spec for now, and once there is spec text for CSS viewport we'll add it there. The <meta> tag is not specified at all at present..

Ah yes, it was linked in the text. Will someone send a pull request for https://github.com/whatwg/compat? Normally we'd block shipping on the spec change being made, and since the Compat spec exists and it sounds like there's multi-vendor support, I think we can stick to that here too, right?

Since Firefox Android would also need to change to get full interop, a stronger statement from Mozilla would be really helpful. Would they be happy to ship this if it turns out to be web compatible in Chrome?

In a discussion with Emilio (cc'd) at TPAC, he informally agreed it's probably fine to switch Firefox Android to match in a similar time frame.

(Emilio, please let me know if I've misquoted in any way. :) )

Sounds good! If we do a compat spec PR, support on that would do the trick. 

--

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANMmsAuM-kW5PP9_%2BF-1y12gE0GK-3Z84YqopTasbUOX6n-ZQw%40mail.gmail.com.

--

Rune Lillesveen

[Philip Jägenstedt]

On Wed, Sep 28, 2022 at 4:01 PM Rune Lillesveen <fut...@chromium.org> wrote:

On Wed, Sep 28, 2022 at 3:38 PM David Bokan <bo...@chromium.org> wrote:

Sure, I'll start on a PR.

Taking another look, there does seem to be some basic parsing of the meta in CSS Viewport. It's still a fairly early-stage spec but I wonder if it'd make more sense to just add the `interactive-widgets` keyword there rather than bouncing it between the two specs? I could also help flesh out the meta processing model more generally there.

That parsing algorithm is something I wrote back in 2010 based on testing Safari on an iPod Touch, not looking at the WebKit source code. That part should just be ditched.

David, I think that answers your question, but whether you want to put the spec for this is fine really, as long as it gets review and some indication of support from another browser vendor, likely Mozilla in this case. 

[Philip Jägenstedt]

 s/whether/wherever/

[slightlyoff via Chromestatus]

Curious why this hasn't been sent to the TAG?

[Chris Harrelson]

(again, speaking as one of the drivers of this intent, not as an API owner)

On Wed, Sep 28, 2022 at 11:43 AM slightlyoff via Chromestatus <admin+sl...@cr-status.appspotmail.com> wrote:

Curious why this hasn't been sent to the TAG?

 I think it's not a significant new API or UX in this case. But we could file an FYI TAG review if you want. Happy to help do that, let me know.

[Rick Byers]

I like this plan, and I agree that having a draft spec seems like a reasonable requirement prior to shipping. I'm very excited to achieve interop here, I know it's a longstanding pain point.

I am worried about the web compat impact. David, will you also have a finch kill-switch so that we can flip the default quickly if needed (eg. during stable roll out)? Worst case could we split out the new API from the default so that sites could explicitly opt-into the new behavior prior to the default changing?

--

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-rD-fW-gaN6aszbjZ81ea0QzycxU-4c%3DcEEqMcu%3DaKsQ%40mail.gmail.com.

[David Bokan]

On Thu, Sep 29, 2022 at 8:44 PM Rick Byers <rby...@chromium.org> wrote:

I am worried about the web compat impact. David, will you also have a finch kill-switch so that we can flip the default quickly if needed (eg. during stable roll out)?

Yup, this will be revertable via Finch.

 Worst case could we split out the new API from the default so that sites could explicitly opt-into the new behavior prior to the default changing?

 We did discuss this as a possibility and this is the fallback plan if we do find too much compat impact. I think the concern with it was that the kind of sites we're worried about are the ones that just won't get updated at all (i.e. it's very low effort to add the opt-out meta and get back to the old behavior), but this could be a useful way to give authors time.

I'll split the flag into two, one for the API and one for the default behavior so we have that control prior to shipping.

[Rick Byers]

On Fri, Sep 30, 2022 at 11:03 AM David Bokan <bo...@google.com> wrote:

On Thu, Sep 29, 2022 at 8:44 PM Rick Byers <rby...@chromium.org> wrote:

I am worried about the web compat impact. David, will you also have a finch kill-switch so that we can flip the default quickly if needed (eg. during stable roll out)?

Yup, this will be revertable via Finch.

Great, figured it would be. 

 Worst case could we split out the new API from the default so that sites could explicitly opt-into the new behavior prior to the default changing?

 We did discuss this as a possibility and this is the fallback plan if we do find too much compat impact. I think the concern with it was that the kind of sites we're worried about are the ones that just won't get updated at all (i.e. it's very low effort to add the opt-out meta and get back to the old behavior), but this could be a useful way to give authors time.

I'll split the flag into two, one for the API and one for the default behavior so we have that control prior to shipping.

Sounds good. I agree it only adds value if we discover some surprise that necessitates a more gradual roll out.

[Mike Taylor]

I see that Emilio has approved https://github.com/w3c/csswg-drafts/pull/7826, with a few suggestions.

LGTM1 to ship w/ the review comments addressed and the PR landing (and thanks for speccing it!).

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/32f2f64f-c49c-4208-b9b9-bd480e64d523n%40chromium.org.

[Yoav Weiss]

LGTM2 under the same conditions!

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/cc5ab134-bc64-4b28-2120-aa6cd672130a%40chromium.org.

[Mike West]

LGTM3.

-mike

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfU-mFYXPwMWpv1WDwN3YwDY-ogU-pKkv9t8-Nson1xWWw%40mail.gmail.com.

[David Bokan]

Thanks everyone!

I'm still waiting on a confirmation for the last remaining issue on the spec PR but I hope to have that resolved and the changes enabled in trunk in the next day or two.

I'll update this thread when that happens.

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/32f2f64f-c49c-4208-b9b9-bd480e64d523n%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/cc5ab134-bc64-4b28-2120-aa6cd672130a%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

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

[David Bokan]

Update: the PR has been merged!

There's been some small changes to naming, the tl;dr, authors will be able to keep the existing OSK resize behavior by adding this meta tag (or modifying their existing one):

<meta name="viewport" content="interactive-widget=resizes-content">

Will land changes in our implementation today to make that match the spec text and then enable in trunk.

Thanks,

David

[Bramus Van Damme]

The explainer has also been updated to match the spec: https://github.com/bramus/viewport-resize-behavior/blob/main/explainer.md#proposal

B!

[David Bokan]

The feature is enabled in trunk with all the changes to match Bramus' explainer (thanks!), as well as an enterprise policy, in time for today's M108 branch.

Please file bugs to me or reply here if you find issues related to this change. Users can undo the change using chrome://flags/osk-resizes-visual-viewport-by-default  to confirm if this change is responsible.

Thanks!

David

[David Bokan]

On Thursday, October 13, 2022 at 11:59:54 AM UTC-4 David Bokan wrote:

Users can undo the change using chrome://flags/osk-resizes-visual-viewport-by-default  to confirm if this change is responsible.

To clarify, setting this flag to "Disabled" will unship this change.