(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. :) ) > > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYeaihvGtV%3D0NuqdPGEuMP664dUEh2%3DO83WYwSCmHOvC%3DA%40mail.gmail.com?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/CAOMQ%2Bw-vptYVgKU8ikvx-0%2BDVigrd6d4k2UiBRrt-b5zKpD8mg%40mail.gmail.com.
