[Bug]: iOS Text clipped and 30% not visible

[scriptease]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/mobile

Steps to reproduce

• Install iPad app version 1.1.0
• Start a session
• Look at the blue message bubbles or mid turn messages
• They are not showing 30% of the text

Expected behavior

• Text area full width or at least show the full text in the smaller area

Actual behavior

• Text clipped, 30% hidden

Impact

Major degradation or frequent failure

Version or commit

iOS app version 1.1.0

Environment

11 inch iPad pro iOS26.7

Logs or stack traces

Screenshots, recordings, or supporting files

IMG_6204.png

Workaround

Rotate device twice you get a permanent 30% white area on the right but the text is now readable in remaining space

[scriptease]

It feels like some of the ui elements make space for the white area (see workaround) when rotated.

In portrait mode the content is not clipped on screen but off screen.

[juliusmarminge]

Thanks for the screenshot and the rotate workaround — this looks like a real iPad chat width / native-markdown clip, not a server or provider issue. Web/desktop reading the same thread is expected: those surfaces do not use the mobile split pane + iOS UITextView markdown path.

What we think is going on

The capture is 11-inch iPad Pro landscape (2388×1668 px → 1194×834 pt) in split view (thread sidebar + chat). In apps/mobile that size is a first-class case:

• deriveLayout / deriveWorkspacePaneLayout in apps/mobile/src/lib/layout.ts (tests already use 1194×834)
• Sidebar is 32% of the window, clamped 280–380 → 380 pt
• Detail/content pane is 814 pt (380/1194 ≈ 31.8%)

That matches both “~30% of the text is missing” and “after two rotations, a permanent 30% white area on the right.”

User (blue) bubbles and in-turn assistant prose go through:

• apps/mobile/src/features/threads/ThreadFeed.tsx — split feed starts viewportWidth at 0, then onLayout; userBubbleMaxWidth = contentWidth * 0.85. Regular user bubbles are shrink-to-fit (maxWidth only). Width is pinned only for “wide” markdown (iOS: blockquotes) or review-comment context.
• apps/mobile/src/features/layout/AdaptiveWorkspaceLayout.tsx — the navigator/feed is frozen at contentSettledWidth (flex: 1 and an explicit width) inside overflow-hidden, so a too-wide measure is clipped rather than reflowed. Composer width follows WorkspaceContentWidthContext; the feed does not.
• apps/mobile/modules/t3-markdown-text/ (SelectableMarkdownText.tsx, T3MarkdownTextShadowNode.mm) — Yoga can give the native text node an unbounded second pass; the parent then clips the painted glyphs instead of wrapping. Work-log rows use ordinary RN Text (thread-work-log.tsx), which matches chrome looking fine while blue bubbles / mid-turn body clip.

The rotate-twice workaround is the tell: first paint measures or wraps against a stale / full-window / unconstrained width while the visible clip is the ~70% detail pane. A later rotation remounts measure at the pane width (text readable) but can leave contentSettledWidth stuck at the sidebar-subtracted column — the white gutter on the right.

iPadOS 26 already has other width/resize bugs in this shell (#10629, #11057); those are toolbar constraints, not this chat clip.

Not a duplicate of

• #10846 — iOS overlapping / garbled assistant glyphs (temporary; leave + re-enter). Same native markdown stack, different symptom and trigger.
• #11119 — Android timestamp/copy and list-badge overlap (also store 1.1.0).
• #8849 — Linux/Wayland Electron min-width clip.
• #8195 — Android DeX / windowed-desktop type clip.

No open PR attributes or fixes this iPad bubble-width clip.

Next

Accepted as an iPad split-layout + iOS native-markdown width bug. Engineering should repro on an 11-inch iPad Pro, landscape, sidebar visible, on store 1.1.0 and current main:

1. Log feed onLayout width vs useWindowDimensions().width vs contentSettledWidth (814 vs 1194 if the 30% math holds).
2. Inspect T3MarkdownText layoutConstraints.maximumSize.width for user bubbles without wide-blocks, and for in-turn assistant rows.
3. After two rotations, check whether the detail column stays at the sidebar-subtracted width while the sidebar is gone.

Until a store/native build ships a fix: rotate twice (text readable, gutter remains) or open the thread on web/desktop.

A couple of extras that would help:

• Whether this is landscape-only or also portrait split (834 pt wide, 280 pt sidebar)
• Whether short user bubbles clip as well, or only long wrapping ones
• Whether hiding the sidebar (without rotating) also restores the text

[scriptease]

The bug also happens in portrait mode but not all of the time. It feels like there's a 50% chance if you have the bug and then it just allocates some space that is not on screen for portrait and on screen for landscape.

So the text is clipped but by the screen edge in portrait or in landscape mode it's clipped by a white box.

[scriptease]

And yes short bubble clip as well, but short bubble texts appear if the view is scrolled out of view and back, so maybe it is a redraw bug? or layouting wrong offscreen with different rectangles.

[juliusmarminge]

Note

Grok responding on behalf of Julius.

#15737 just merged a fix for iOS native markdown replies being clipped (the last lines of a reply staying hidden until a redraw), which looks like the same layout bug behind this one. Closing this in favor of that fix. If you still see clipped text on iPad on a build that includes #15737, please reopen with a screenshot and we'll dig back in.