Handling virtualkeyboard placement #12
Conversation
…hould be handled by Block only, so e.g. no margins/ paddings on the root container.
|
Is the updateViewport() method there only to tame Safari? Or is that also needed for Chrome? I think we should forget about Safari for now, and tackle cross-browser compatibility in a separate development round, and re-evaluate based on the timing. If the timing is early, we may drop CSS anchor positioning if we want to target both browsers (to avoid two implementation paths). Or we sit it out, and wait till CSS Anchor Positioning is supported in Safari as well. It's good however we have a potential solution for handling virtual keyboard placement, so we should keep this PR around for reference. Could you maybe make another PR that only includes the minimum amount of code to make this work in Chrome/Android (without the safari workarounds)? I'll try to get myself an Android phone for testing our mobile solution. Can't do any tests atm. |
|
FYI: The clipboard solution currently also only supports Chrome. I know about a workaround for Safari, but wanted to keep things minimal for now. |
|
Yes the updateViewport() method is only needed for Safari, though I haven't tested with Android either. I can borrow an Android Phone later today, so I can check and then create a separate minimal version that targets Chrone only. |
|
This image sums up the issue: in chromium the visible viewport resizes, in Safari it stays the same. |
|
The additional problem on iOS is that if the focused input is either too low or too high, it will offset the viewport
|
|
How does everyone else solve this? Seems they don't … For example Notion/ Fibery/ LinkedIn/ ... have their toolbar fixed over the keyboard in their native apps, but floating somewhere on the screen near the selection in their web apps. This works for them since the blocks one select here are usually just a single line of text, and not a block that spans multiple rows/ an area beyond the visible screen. But it's also create the terrible UX where you have both the native text actions visible (copy/paste/…) and the custom floating toolbar ... so not really a great experience on the web in these apps ...
|
|
Another insight: regardless of the placement of the toolbar we need to manually control wether the virtual keyboard should be shown or hidden, otherwise click on any tool will cause the keyboard to disappear (toolbar moves) as the focus is no longer on a "text" node. There's a new API for this: RPReplay_Final1729337411.MP4 |
|
We may be able to keep the selection when clicking the tools, if we use preventdefault. However, we need to careful that this doesn’t mess with other behavior. |
|
These properties may help with the iOS context menu appearing for text selections: |
|
Just cleaning up? As the problem still persists. The proposed solution in this PR with |
|
Sorry, will reopen it. Just thought that we need generally a different approach to this. |
|
Relevant docs for fixing the virtual keyboard resize issues: https://developer.mozilla.org/en-US/docs/Web/API/VirtualKeyboard_API https://developer.mozilla.org/en-US/docs/Web/CSS/env#keyboard-inset-top https://www.htmhell.dev/adventcalendar/2024/4/ https://interop-2022-viewport.netlify.app/combined/viewport-units/ |
So after trying like two dozen different techniques I finally found a solution that works well in Chromium (Android) and semi-ok in Safari. In Safari there are temporary placment issues of the toolbar when the viewport shifts (the user scrolls, but the browser doesn't actually scroll the page, but instead moves the visual viewport up / down until the "edge" is reached" ... hard to explain in words … but it's a known issue and there are several bug reports for Safari. The solution for chromium is just a line of css and an additional meta viewport tag attribute.