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? On Sat, Sep 24, 2022 at 4:17 AM David Bokan <bo...@chromium.org> wrote: > 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 > <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 blink-dev+unsubscr...@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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/32f2f64f-c49c-4208-b9b9-bd480e64d523n%40chromium.org?utm_medium=email&utm_source=footer> > . > -- 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+unsubscr...@chromium.org. 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.
