[Bug]: Trackpad swipes over inline HTML renders are dropped after a direction change (macOS desktop)#23864

Before submitting

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

Area

apps/web

Steps to reproduce

1. On macOS, open the desktop app in a thread whose assistant replies include several inline html_render pages. Mine are diagram and table pages about 1,300 to 2,200 px tall, all fitted to their content (no inner scrollbar).
2. Put the pointer over one of the renders.
3. Scroll with the built-in trackpad, flicking a few screens at a time and alternating direction (up, down, up, ...).

Expected behavior

Every swipe scrolls the thread, as it does over plain chat text.

Actual behavior

Swipes are dropped, often right after a direction change. The thread does not move, and the render under the pointer does not visibly move either. Repeating the swipe in the same direction usually works. In practice you have to swipe twice every time you change direction.

Cause

Some fitted render frames are a fraction of a pixel shorter than their page, so the page can scroll inside its frame by 0.5 px.

In the running desktop app (current main, 60b35a1ee0), I read the scroll state inside each inline render frame over the DevTools protocol. Three of the six frames in the thread had a vertical scroll range of 0.5 px. For example, one frame was 1,366 px tall and its page measured 1,366.5 px. At 2x scale, that is one device pixel.

Chromium latches a trackpad gesture to the innermost frame that can scroll in the gesture's direction, even by one device pixel:

• A swipe that the frame can absorb latches to it. The frame moves by its 0.5 px and the rest of the swipe is lost.
• That leaves the frame at one end of its range. The next swipe the same way can't scroll it, so it reaches the thread. That swipe works.
• A swipe in the opposite direction can scroll the frame again, so it latches and is lost.

That matches the "reversal lost, repeat works" pattern below.

A minimal page reproduces it. In headless Chrome with synthesized trackpad gestures, put a cross-site sandbox="allow-scripts" iframe, 1,500 px tall, in a scrollable parent, and load this page in it:

7 of 10 alternating swipes over the frame moved neither the frame visibly nor the parent. With scrolling="no" on the iframe, 0 of 10 were lost.

I did not pin down why the frame ends up short. Forcing a window resize corrected that frame to 1,367 px, so the frame's height had fallen behind the page's last reported size. The bootstrap rounds the page height up and only posts a size message when that rounded value changes (if(v===h)return), so a size report the host misses is never sent again.

I missed this at first. Loaded on its own in a test page at the same column width, each of these renders fits its frame exactly.

Measurements

I recorded a session on 0.1.1 to measure the symptom. Scroll events came from a listen-only macOS event tap (deltas, finger and momentum phases, pointer position), and the screen was captured at 60 fps. Both use wall-clock timestamps, so each swipe lines up with the thread's on-screen motion. I measured motion by aligning consecutive frames of the chat column. A swipe counts as lost if the thread moved less than 35% of the finger's travel.

Results for 96 swipes over the chat column in 86 seconds:

The first swipe has no previous swipe, so it isn't in the direction rows.

• 26 of the 37 lost swipes moved the thread exactly 0 px.
• From 43.5 s to 46.6 s, 10 consecutive alternating swipes of up to 1,502 px each moved nothing. The frames before and after each one are pixel-identical around the pointer. A 0.5 px move inside the render is below the capture's 1 px = 1 pt resolution.
• The pause before a swipe and whether momentum from the previous swipe was still running made no clear difference (30 to 42% lost in every group). The direction change did.

Possible fix

Draft PR: #23865

It sets scrolling="no" on inline render frames while they are fitted to their page. That makes the page unable to scroll its own viewport by user input, so Chromium never latches a swipe to the frame. The page's own scrollable elements, wheel handlers, and script-driven scrolling keep working. Frames for pages past HTML_RENDER_MAX_FIT_HEIGHT keep scrolling. The fix is in the host because the bootstrap is baked into each render when it is published, so a bootstrap change would not reach existing renders.

On a dev build of main with the same thread and trackpad, counting swipes with the pointer over a render:

The swipes still counted as lost with the fix either came before the app window was in front or overlapped momentum from the previous swipe, where my frame-motion measurement is least reliable. In use, the double swipe is gone.

The short frame height is a separate bug. The fix above does not depend on it.

Related

• Renders past 2,000 px remount at the cap. Render frames unload when they leave the timeline's render window. When one scrolls back in, it remounts at HTML_RENDER_MAX_HEIGHT (2,000 px) until the page reports its height (2,178 px for one of mine). While capped, the page has a real inner scroll range. In nine back-and-forth flicks, frames remounted 7 times and one was capped for about 1.85 s in total. The PR treats a frame with no reported height yet as fitted, so this case is covered too.
• #16977 (wheel stuck on a tall render; fixed for fitted renders by #22131) and #17056.

Impact

Major degradation or frequent failure

Version or commit

Reported on 0.1.1 (fe27e8e3dc12). Reproduced on main at 60b35a1ee0.

Environment

macOS 26.5, T3 Code (Beta) desktop 0.1.1 (Electron 44.4.5), MacBook Pro built-in trackpad, 1312×848 pt Retina display

Workaround

After a swipe does nothing, swipe the same direction again. Scrolling with the pointer in the margin outside the chat column avoids the renders.