Contact emails
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.
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 risksThere is no intended behavior change for Android WebView. The Android app is responsible for sizing the WebView and can implement either mode via windowSoftInputMode.
DebuggabilityN/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 nameOSKResizesVisualViewport
Requires code in //chrome?Yes - Interaction between web contents container and on-screen keyboard is implemented in the //chrome layer.
Tracking bugM108
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.
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.
--
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.
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?
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.
(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. :) )
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.
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.
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.
Curious why this hasn't been sent to the TAG?
--
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.
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?
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.
--
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.
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.
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.
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.
Users can undo the change using chrome://flags/osk-resizes-visual-viewport-by-default to confirm if this change is responsible.