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 On Tuesday, October 11, 2022 at 7:20:20 PM UTC-4 Bramus Van Damme wrote: > The explainer has also been updated to match the spec: > https://github.com/bramus/viewport-resize-behavior/blob/main/explainer.md#proposal > > B! > > > On Tuesday, October 11, 2022 at 5:26:54 PM UTC+2 David Bokan wrote: > >> Update: the PR has been merged >> <https://github.com/w3c/csswg-drafts/pull/7826>! >> >> 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 >> >> On Monday, October 10, 2022 at 2:34:41 PM UTC-4 David Bokan wrote: >> >>> Thanks everyone! >>> >>> I'm still waiting on a confirmation for the last remaining issue on the >>> spec PR >>> <https://github.com/w3c/csswg-drafts/pull/7826#discussion_r990725831> 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. >>> >>> On Friday, October 7, 2022 at 5:52:39 AM UTC-4 Mike West wrote: >>> >>>> LGTM3. >>>> >>>> -mike >>>> >>>> >>>> On Fri, Oct 7, 2022 at 4:56 AM Yoav Weiss <[email protected]> >>>> wrote: >>>> >>>>> LGTM2 under the same conditions! >>>>> >>>>> On Fri, Oct 7, 2022 at 2:23 AM Mike Taylor <[email protected]> >>>>> wrote: >>>>> >>>>>> 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!). >>>>>> >>>>>> On 9/23/22 10:17 PM, David Bokan wrote: >>>>>> >>>>>> 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 >>>>>> >>>>>> <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 [email protected]. >>>>>> 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 >>>>>> >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/cc5ab134-bc64-4b28-2120-aa6cd672130a%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 [email protected]. >>>>> >>>> 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 >>>>> >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfU-mFYXPwMWpv1WDwN3YwDY-ogU-pKkv9t8-Nson1xWWw%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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d208ec7f-8290-441e-bf77-c90274518f2dn%40chromium.org.
