Contact emails
[email protected] 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 <https://drafts.csswg.org/css-viewport/#viewport-meta>. 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] <https://stackoverflow.com/questions/52384678/how-to-stop-soft-keyboard-resizing-chrome-browser-window-on-android-mobiles> [2] <https://stackoverflow.com/questions/67800763/how-to-avoid-the-android-keyboard-is-closed-automatically-after-i-click-on-an-in> [3] <https://medium.com/@sruthisreemenon/avoid-ui-distortions-during-keyboard-display-for-a-mobile-friendly-webpage-86eb99590a13> [4] <https://bugs.chromium.org/p/chromium/issues/detail?id=404315>. 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 <https://wpt.fyi/interop-2022>. Mobile viewports (especially the meta tag) are unfortunately not well specified, and we plan to work on resolving CSSWG issue 7767 <https://github.com/w3c/csswg-drafts/issues/7767> in parallel with this intent. In the meantime we plan to add this feature to the Compat spec <https://compat.spec.whatwg.org/>. Blink component Blink>Scroll <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EScroll> 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 <https://groups.google.com/a/chromium.org/g/blink-dev/c/Tr43oT4DQoY/m/XRxLWmrrEQAJ> at LGTM2. What makes this intent different: - The VirtualKeyboard API <https://developer.chrome.com/docs/web-platform/virtual-keyboard/> 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 <https://github.com/mozilla/standards-positions/issues/693>] (Some non-official positive signals from Mozilla engineers from discussions at TPAC and in 7767 <https://github.com/w3c/csswg-drafts/issues/7767#issuecomment-1251680898> that Firefox could make this change) WebKit: No response yet [standards position <https://github.com/WebKit/standards-positions/issues/65>]. 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 <https://developer.android.com/guide/topics/manifest/activity-element#wsoft> . 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 <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> ? 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 <https://bugs.chromium.org/p/chromium/issues/detail?id=1353728> 404315 <http://crbug.com/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 <https://github.com/w3c/csswg-drafts/issues/7590>. Link to entry on the Chrome Platform Status https://chromestatus.com/feature/6145225857171456 -- 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 [email protected]. 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.
