Launch bar vanishes after portrait → landscape orientation change

[Nriver]

Description

The launch bar disappears in the mobile browser when switching from portrait to landscape orientation. It remains visible if the page is started in landscape mode, and the transition from landscape to portrait works correctly.

portrait → landscape

1.mp4

landscape → portrait

2.mp4

TriliumNext Version

source code

What operating system are you using?

Other Linux

What is your setup?

Server access only

Operating System Version

Manjaro

Error logs

No response

[dosubot]

This looks like it's caused by the virtual keyboard detection logic producing a false positive during orientation changes.

The mobile launch bar is hidden via display: none !important whenever the virtual-keyboard-opened class is present on the root widget [1]. That class is toggled by #onMobileResize() in root_container.ts, which compares the current viewport height against a stored originalWindowHeight [2]:

#onMobileResize() {
    const viewportHeight = window.visualViewport?.height ?? window.innerHeight;
    const windowHeight = Math.max(window.innerHeight, this.originalWindowHeight);
    const isKeyboardOpened = windowHeight - viewportHeight > 150;
    this.$widget.toggleClass("virtual-keyboard-opened", isKeyboardOpened);
}

The problem is that originalWindowHeight is captured once during construction [3] and never updated on orientation change. When you rotate portrait → landscape, the portrait height (e.g. ~800px) is still used as the baseline, but the landscape viewport height is much shorter (e.g. ~400px). The difference exceeds the 150px threshold, so the code incorrectly concludes the keyboard is open and hides the launch bar. Landscape → portrait works fine because the new viewport height is larger than the stored baseline, keeping the difference negative.

Key files to modify:

• root_container.ts — the virtual keyboard detection logic
• style.css — the CSS rule hiding the bar

A fix could involve listening for orientationchange (or checking screen.orientation) and resetting originalWindowHeight when the orientation actually changes, then re-evaluating keyboard state after dimensions stabilize. Alternatively, combining the height heuristic with a check on whether an input/editable element is focused would make keyboard detection more robust.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.