#20874: Bug: Native rich-text field is unusable on mobile with soft keyboard open + long content

Bug: Native rich-text field is unusable on mobile with soft keyboard open + long content

Affects: Mobile web (iOS Safari / Android Chrome), record field of type FieldMetadataType.RICH_TEXT (BlockNote-based), opened from the Fields widget in record detail.

---

Bug Description

When a record field of type rich-text contains more content than fits the visible viewport and the soft keyboard is open on a mobile device:

1. The "expand to fullscreen" trigger is unreachable — covered or pushed out of the visible area by the keyboard, with no way to scroll to or activate it.
2. The content area scrolls erratically under the keyboard — positioning the cursor precisely is difficult or impossible.
3. The user cannot read the existing field content while editing — the visible area shrinks to a few lines and scrolling behaviour is unreliable.

There is no apparent gesture, button, or configuration option to enter a reliable fullscreen edit mode on mobile once the keyboard is open.

---

Steps to Reproduce

1. Create a custom field of type rich-text on any object (e.g. on Company).
2. Open a record of that object and add enough content to the rich-text field to exceed one screen of text.
3. Open the same record on a mobile device (iOS Safari or Android Chrome).
4. In the Fields widget of the record detail, tap the rich-text field to open the editor — soft keyboard opens.
5. Try to scroll through the existing content, reach the fullscreen trigger, or place the cursor in a specific location.

Expected: A fullscreen / modal edit mode activates automatically (or via an always-visible, keyboard-aware trigger) so the user can comfortably read and edit longer content on mobile.

Actual: The visible editing area shrinks to a few lines, the fullscreen trigger is inaccessible, and scrolling is unreliable.

---

Why This Matters

Since FRONT_COMPONENT widgets cannot reliably use <input> / <textarea> for user-editable text (Worker bridge filters value / defaultValue and related props), the native rich-text field is effectively the only path for editing longer text content inside a record. Mobile usability of this single remaining path is therefore critical for the "edit a longer note from the phone" scenario — which is core CRM territory.

---

Environment

• Twenty version tested: 2.4.0 (we are currently blocked from upgrading by upstream upgrade issues — see #20841 and #20699 — so we cannot verify on v2.7.3 directly)
• Latest release at time of writing: v2.7.3 (Docker) / 2.7.0 (npm SDK)
• Browsers: iOS Safari 17, Android Chrome 124
• Devices: iPhone 15, Pixel 7

---

Related

• #6913 — Minor bugs in notes pages (mobile viewport clipping)
• #7447 — Minor bug in column scroll in mobile viewport
• PR #11390 — Add Edit Rich Text functionality to table view (CommandMenuEditRichTextPage)

---

Question for Maintainers

Has the native rich-text editor been tested on mobile with longer content + soft keyboard open? If there is a recommended UX pattern (e.g. via CommandMenuEditRichTextPage from PR #11390) to enter a true fullscreen edit mode on mobile, it is not currently discoverable from the Fields widget.