Search input gets hidden under keyboard until user starts typing

aniram commented

2026-02-19 00:42:10 +00:00

Owner

Suggestion: Quick investigation. 1h max. If a solution is not found add an item to the UI refactoring issue to put the search input at the top to get rid of future problems, this has already cost me a lot of time.

The problem:
While the user scrolls the browser's navigation bar, where the URL is, disappears to increase the screen's visible area.
This behavior causes the input field to get stuck under the keyboard when the user clicks inside the search input after it was expanded. Only when the user starts typing does the input become visible again. This only occurs when the user tries to type while they are scrolling. If the page isn't moving then the navigation bar is present, and this does not happen.
Firefox on Android does not make the navigation bar disappear so this does not happen.
The navigation bar being on the bottom is not the default setting.

Suggestion: Quick investigation. 1h max. If a solution is not found add an item to the UI refactoring issue to put the search input at the top to get rid of future problems, this has already cost me a lot of time. The problem: While the user scrolls the browser's navigation bar, where the URL is, disappears to increase the screen's visible area. This behavior causes the input field to get stuck under the keyboard when the user clicks inside the search input after it was expanded. Only when the user starts typing does the input become visible again. This only occurs when the user tries to type while they are scrolling. If the page isn't moving then the navigation bar is present, and this does not happen. Firefox on Android does not make the navigation bar disappear so this does not happen. The navigation bar being on the bottom is not the default setting.

aniram added the

Kind/Bug

Priority/Low

Agent/Chrome-Android

labels

2026-02-19 00:42:10 +00:00

aniram changed title from ~~Search input gets hidden under keyboard until the user starts typing~~ to Search input gets hidden under keyboard until user starts typing

2026-02-19 00:42:21 +00:00

aniram commented

2026-02-19 00:59:35 +00:00

Author

Owner

On some websites like https://devdocs.io/javascript the browser's navigation bar does not disappear on scrolling.

aniram commented

2026-02-19 20:56:55 +00:00

Author

Owner

https://developer.mozilla.org/en-US/docs/Web/API/VirtualKeyboard_API#browser_compatibility

aniram commented

2026-02-21 13:42:30 +00:00

Author

Owner

Using the VirtualKeyboard API could solve this problem but at the same time it would potentially create many others as this is a low-level API that instead of letting the browser push the viewport up to show the keyboard, it lays the keyboard over it, making it 100% our responsibility to modify the viewport on keyboard open and close events. Currently I have a small POC working on branch feat/use-virtual-keyboard-api but it has a bug on Chrome as this API is currently only available there.

The bug is as follows:
I'm on the homepage, no results are shown.
I click on the address bar and then on the URL. The keyboard shows up.
It does not appear on the page where I was but instead on a browser specific page.
This is normal behavior. So far so good.
If while I'm on this page I click on the URL under the address bar which happens to be the URL of the page I was in then the browser will trigger a page refresh.
Here comes the bug.
The new page will now have as its height the viewport height plus the keyboard height although the keyboard is not visible anymore as it got dismissed when the page refreshed. Since I'm using the Virtual Keyboard API the keyboard is overlaying the content which now means it's hiding the search button as the screenshot shows.
Clicking on the page, brings focus to the document and makes the search button appear as well as the viewport height to back to its normal value.
On the screenshots we can see a picture where the height is 1932px and the search button is hidden, and another one where the height is 1381px with a visible button.

Proposed solution:
I've investigated how OpenAI™ ChatGPT hides and shows the text area where users enter their prompt to the LLM.
They use the VirtualKeyboard API in a more selective way. Instead of listening to the geometrychange event, that is fired whenever the keyboard enters/leave, to change the viewport's height they first listen to the focusin event and only then do they opt-in on the VirtualKeyboard API and add the event listeners for geometrychange. This ensures that the page will adapt its layout to keyboard related events only when the page receives user focus. Without it, by opting in to the VIrtualKeyboard API per default, we have to deal with all kinds of possible edge-cases we don't want to, so we should only opt-in in when our usage case actually happened. After the keyboard was dismissed, they clean-up by opting out again.

The code below belongs to OpenAI™ and is shown here only as a case-study.
On the very bottom I've added some commentary of my own.

1a7ebd5f-n8t4mic0ryk6vjax.js

function vpt() {
    if (!Zk())
        return;
    const t = SPe();
    let e = !1;
    const s = navigator.virtualKeyboard.overlaysContent;
    function n() {
        if (e)
            return;
        t.reset(),
        document.removeEventListener("focusout", o),
        vPe(),
        document.body.style.removeProperty("--screen-keyboard-height"),
        navigator.virtualKeyboard.removeEventListener("geometrychange", a);
        let l;
        const c = u => {
            u.target.boundingRect.height === 0 && setTimeout( () => {
                t.events.dispatch("keyboard-closed"),
                window.clearTimeout(l)
            }
            , 100)
        }
        ;
        l = window.setTimeout( () => {
            navigator.virtualKeyboard.removeEventListener("geometrychange", c),
            t.events.dispatch("keyboard-closed")
        }
        , 500),
        navigator.virtualKeyboard.addEventListener("geometrychange", c)
    }
    const o = () => {
        e = !1,
        t.isKeyboardOpen.set(!1),
        requestAnimationFrame(n)
    }
      , a = l => {
        document.body.style.setProperty("--screen-keyboard-height", "".concat(l.target.boundingRect.height, "px")),
        bPe(),
        t.keyboardDimensions.set(l.target.boundingRect),
        t.keyboardHeight.set(l.target.boundingRect.height)
    }
      , i = l => {
        const c = l.target;
        xPe(c) && (e = !0,
        t.focusedElement.set(c),
        t.isKeyboardOpen.set(!0),
        t.events.dispatch("keyboard-opened"),
        document.addEventListener("focusout", o),
        navigator.virtualKeyboard.addEventListener("geometrychange", a))
    }
    ;
    // Sets overlaysContent to true, listens to focusin event with function 'i' and
    // returns callback that cleans up by toggling the overlaysContent value,
    // removes the event listener and calls clean-up function 'n'.
    // Function 'i' dispatches a keyboard-opened event and adds function 'a' as callback
    // the event listener on geometrychange.
    // Function 'a' then finally adds a property to the body called --screen-keyboard-height with the height
    // of the keyboard which is used somewhere else to push the textarea up by this many pixels.
    return navigator.virtualKeyboard.overlaysContent = !0,
    document.addEventListener("focusin", i),
    () => {
        navigator.virtualKeyboard.overlaysContent = s,
        document.removeEventListener("focusin", i),
        n()
    }

Using the VirtualKeyboard API could solve this problem but at the same time it would potentially create many others as this is a low-level API that instead of letting the browser push the viewport up to show the keyboard, it lays the keyboard over it, making it 100% our responsibility to modify the viewport on keyboard open and close events. Currently I have a small POC working on branch **feat/use-virtual-keyboard-api** but it has a bug on Chrome as this API is currently only available there. The bug is as follows: I'm on the homepage, no results are shown. I click on the address bar and then on the URL. The keyboard shows up. It does not appear on the page where I was but instead on a browser specific page. This is normal behavior. So far so good. If while I'm on this page I click on the URL under the address bar which happens to be the URL of the page I was in then the browser will trigger a page refresh. Here comes the bug. The new page will now have as its height the viewport height plus the keyboard height although the keyboard is not visible anymore as it got dismissed when the page refreshed. Since I'm using the Virtual Keyboard API the keyboard is overlaying the content which now means it's hiding the search button as the screenshot shows. Clicking on the page, brings focus to the document and makes the search button appear as well as the viewport height to back to its normal value. On the screenshots we can see a picture where the height is 1932px and the search button is hidden, and another one where the height is 1381px with a visible button. Proposed solution: I've investigated how OpenAI™ ChatGPT hides and shows the text area where users enter their prompt to the LLM. They use the VirtualKeyboard API in a more selective way. Instead of listening to the **geometrychange** event, that is fired whenever the keyboard enters/leave, to change the viewport's height they first listen to the **focusin** event and only then do they opt-in on the VirtualKeyboard API and add the event listeners for **geometrychange**. This ensures that the page will adapt its layout to keyboard related events only when the page receives user focus. Without it, by opting in to the VIrtualKeyboard API per default, we have to deal with all kinds of possible edge-cases we don't want to, so we should only opt-in in when our usage case actually happened. After the keyboard was dismissed, they clean-up by opting out again. The code below belongs to OpenAI™ and is shown here only as a case-study. On the very bottom I've added some commentary of my own. **1a7ebd5f-n8t4mic0ryk6vjax.js** ```js function vpt() { if (!Zk()) return; const t = SPe(); let e = !1; const s = navigator.virtualKeyboard.overlaysContent; function n() { if (e) return; t.reset(), document.removeEventListener("focusout", o), vPe(), document.body.style.removeProperty("--screen-keyboard-height"), navigator.virtualKeyboard.removeEventListener("geometrychange", a); let l; const c = u => { u.target.boundingRect.height === 0 && setTimeout( () => { t.events.dispatch("keyboard-closed"), window.clearTimeout(l) } , 100) } ; l = window.setTimeout( () => { navigator.virtualKeyboard.removeEventListener("geometrychange", c), t.events.dispatch("keyboard-closed") } , 500), navigator.virtualKeyboard.addEventListener("geometrychange", c) } const o = () => { e = !1, t.isKeyboardOpen.set(!1), requestAnimationFrame(n) } , a = l => { document.body.style.setProperty("--screen-keyboard-height", "".concat(l.target.boundingRect.height, "px")), bPe(), t.keyboardDimensions.set(l.target.boundingRect), t.keyboardHeight.set(l.target.boundingRect.height) } , i = l => { const c = l.target; xPe(c) && (e = !0, t.focusedElement.set(c), t.isKeyboardOpen.set(!0), t.events.dispatch("keyboard-opened"), document.addEventListener("focusout", o), navigator.virtualKeyboard.addEventListener("geometrychange", a)) } ; // Sets overlaysContent to true, listens to focusin event with function 'i' and // returns callback that cleans up by toggling the overlaysContent value, // removes the event listener and calls clean-up function 'n'. // Function 'i' dispatches a keyboard-opened event and adds function 'a' as callback // the event listener on geometrychange. // Function 'a' then finally adds a property to the body called --screen-keyboard-height with the height // of the keyboard which is used somewhere else to push the textarea up by this many pixels. return navigator.virtualKeyboard.overlaysContent = !0, document.addEventListener("focusin", i), () => { navigator.virtualKeyboard.overlaysContent = s, document.removeEventListener("focusin", i), n() } ```

with-button.png

624 KiB

no-button.png

632 KiB

aniram added reference feat/use-virtual-keyboard-api

2026-02-21 18:52:28 +00:00

aniram commented

2026-02-24 07:59:37 +00:00

Author

Owner

Try using this instead of manually toggling CSS classes.

.your-input {
  bottom: env(keyboard-inset-height, 0px);
}

Try using this instead of manually toggling CSS classes. ```css .your-input { bottom: env(keyboard-inset-height, 0px); } ```

Rows
Columns

Search input gets hidden under keyboard until user starts typing #58