Fix Collabora Online Mobile Web View Keyboard Covering Text

If the on-screen keyboard covers the paragraph, cell, or search field you are editing in Collabora Online, first find out where the problem lives: in the document editor, the mobile browser, or the app that embeds Collabora in a WebView. On a phone, the keyboard can reduce the visible part of a page without resizing every element in the page layout. The editor may keep its old position while the browser or host app handles the smaller visible area differently.

Start with the checks below before changing server settings. A quick comparison between the same document in the embedded view and a standalone browser often tells you whether the fix belongs to the document host. If you maintain the Android app or website, inspect how your host handles the keyboard and WebView insets before adding custom scripts.

What should you check first?

1. Save the document, then reopen the same file in an up-to-date standalone browser on the same phone.
2. Tap the same text or spreadsheet input, open the keyboard, and note whether the caret and text remain visible.
3. Repeat in the original app or embedded web view. If only the embedded version fails, record the host app and WebView as part of the problem.
4. Try rotating the phone or zooming out one step. These are diagnostic workarounds; they do not repair a broken viewport.

Collabora describes Online as browser-based and says it supports current mainstream browsers; it also offers separate mobile apps. Those are distinct ways to access documents, so test the one you actually use. See Collabora Online’s product information and Collabora’s mobile-app information. Action: compare the same document, account, and input field in your normal app and in the standalone browser before changing settings.

Why does the keyboard cover text?

Mobile web pages have a layout viewport and a visual viewport. The layout viewport describes the page’s layout area, while the visual viewport is the portion currently visible on screen. When a virtual keyboard appears, browsers may shrink the visual viewport and scroll toward the focused field. The exact behavior varies by browser and embedding context. If a document editor, browser, or native host assumes the old viewport height, the active content can end up behind the keyboard.

This distinction is documented by MDN’s reference for VisualViewport. It explains the underlying web behavior; it does not establish that a particular Collabora release has a confirmed defect. Action: use the standalone-browser comparison to determine whether the issue follows the editor across browsers or appears only inside one host.

Fixes for someone editing a document

1. Update and reopen the editing context

Install available updates for the mobile browser or host app, close the document, and open it again. This can resolve a stale page state or a version-specific issue, but it is not a guaranteed fix for a viewport bug. Avoid relying on a cached tab that has remained open through browser or operating-system updates. Action: test again after a full close and reopen, then note the browser or app version if the keyboard still hides the caret.

2. Use the standalone browser as a comparison or temporary workaround

If Collabora is opened from a cloud-storage app, email client, or custom portal, use that service’s “open in browser” option if available. If text remains visible in the standalone browser, the app’s embedded WebView or its native screen layout is a stronger suspect. If both versions fail in the same way, the problem may instead involve the browser engine, operating system, editor version, or a specific Collabora control.

Do not assume the standalone browser is always the permanent answer: the host may be required for authentication or file saving. Action: use the route that keeps the caret visible for urgent edits, and report the comparison to the service or app maintainer.

3. Make more room while you work

As short-term workarounds, rotate the device to landscape, reduce page zoom slightly, scroll the document so the active paragraph is higher on screen, or dismiss the keyboard between edits. In Calc, the formula input area or a cell-editing control may behave differently from direct editing in the grid, so test the specific control that hides. These steps can make the focused content visible; they do not prove that the app’s viewport handling is correct.

Action: repeat the same edit after each workaround and check that you can see both the insertion point and the surrounding text. If only one toolbar field or search box is obscured, report that field specifically rather than describing the entire document as unusable.

Is this a known Collabora issue?

Some recent Collabora reports describe mobile controls becoming hidden when the keyboard appears, but they are tied to particular devices, app versions, and workflows. For example, a September 2026 report describes a search field hidden by the keyboard in the Collabora mobile app on iOS and iPadOS; it is labeled unconfirmed in the project’s issue tracker. That report is evidence of a reported symptom, not proof that every Collabora Online mobile browser has the same bug or that a fix is available. Review the Collabora mobile search-field report for its exact scope.

Action: check the issue’s status and version details before treating it as your case. A user in a browser-based Collabora session should also state clearly that the problem occurs in the web version, rather than in Collabora Office’s native mobile app.

What should an Android WebView developer inspect?

If your app embeds Collabora Online in Android WebView, inspect the host activity’s soft-keyboard and window-inset behavior. Android’s guidance says an activity can request that its window resize when the keyboard opens with android:windowSoftInputMode="adjustResize". Android also documents modern WebView window insets: consuming or failing to pass inset changes can prevent the WebView from receiving viewport updates, and can interfere with behavior such as scrollIntoView(). Read the current Android input-method visibility guidance and Android’s WebView window-insets guide.

adjustResize is a useful place to start, not a universal one-line patch. Edge-to-edge layouts, Android versions, custom inset listeners, parent containers, and WebView placement can affect the result. In particular, do not consume keyboard insets without understanding how descendants receive them. Action: test a minimal host screen with a WebView and a standard editable field, then compare its keyboard behavior with the Collabora page. Change one host setting at a time and retest scrolling, caret visibility, and keyboard dismissal.

On iOS, a native app embedding a web view should be checked in the host app’s UIKit/WebKit layout as well as in the page itself. Apple documents keyboard-aware layout through UIKit’s keyboardLayoutGuide. This is platform guidance for app developers, not an end-user setting for a Collabora document.

Should you add JavaScript or CSS to Collabora?

Usually, do not start by injecting CSS into the editor iframe or changing Collabora’s document layout. The VirtualKeyboard API can let a web application take direct control of keyboard overlays, but MDN marks it as limited availability and explains that opting out of the browser’s normal resizing behavior requires the page to manage the keyboard geometry itself. The visual viewport inside an iframe also does not necessarily report the same measurements as the top-level page. See MDN’s VirtualKeyboard API reference and VisualViewport reference.

Action: use the supported integration and host-app configuration first. Only add a page-level workaround if you maintain the integration, have reproduced the issue on the target devices, and can test the editor’s embedded frame without disrupting document input or saving.

How do you report a reproducible problem?

Send the administrator or app developer a short report with:

• Phone or tablet model, operating-system version, and keyboard app if relevant.
• Browser name and version, or the host app name and version if a WebView is involved.
• Collabora Online version when known, plus the cloud or portal integration used.
• Document type and the exact control that becomes hidden, such as Writer text, a Calc cell, the formula bar, or a search field.
• Whether the same document works in a standalone browser, and whether portrait or landscape changes the result.
• A brief screen recording with private document contents removed or obscured.

Collabora’s issue tracker asks mobile reporters to include device and operating-system versions, app version, reproduction steps, expected behavior, and actual behavior. Follow its issue-reporting page and avoid posting confidential documents or authentication details.

How can you tell whether it is fixed?

Reopen the same file and repeat the same edit with the keyboard visible. The focused text or cell should remain visible; the caret should be where you expect; you should be able to type, scroll to the next paragraph or cell, and dismiss the keyboard without the page jumping or losing focus. Repeat once in portrait and once in landscape, then test the embedded app and standalone browser separately if both matter to your workflow.

If only one path still fails, keep the diagnosis scoped to that browser, app, or control. That evidence helps the maintainer decide whether to investigate Collabora’s mobile editor, the browser viewport, or the native WebView container.