[macOS][26.908.40834] Completed inline visualization table repeatedly blanks while scrolling the parent conversation

What version of the Codex App are you using (From “About Codex” dialog)?

ChatGPT/Codex desktop 26.908.40834, build 8881 (installed macOS bundle metadata). The affected surface is the Codex work interface inside ChatGPT.app.

What subscription do you have?

Not included in this public rendering report.

What platform is your computer?

macOS 27.0 (26A428), arm64.

What issue are you seeing?

A completed inline visualization repeatedly loses the lower part of its HTML table while scrolling the parent conversation. Rows disappear into a large blank rectangle and return during continued scrolling. The faulty region moves with the embedded content; surrounding prose, sidebar, and composer remain stable in the recordings.

The component contains four SVG device outlines, CSS bars, and a 19-row, four-column comparison table. This is reproducible when reading an already rendered component, without new tokens being appended to that component. It makes the comparison difficult to read.

Observed controls on the affected machine:

• Original inline component: visible blanking/flicker during parent scrolling.
• Revised inline component without the custom ResizeObserver script: still flickers. This revision also changed SVG sizing to CSS container units, so it is not a perfect single-variable experiment.
• The same comparison delivered as a static PNG plus native Markdown table: the user explicitly confirmed no flicker.

Three performance traces were collected. The third was recorded simultaneously with a screen recording while the user reproduced the problem in both inline variants. The recording shows the trace start, reproduction, trace stop, and local save sequence. Ordinary application logs did not contain a matching renderer/GPU crash during the earlier recorded reproductions; that absence does not rule out a rendering defect.

What steps can reproduce the bug?

Observed steps on the affected machine:

1. Use the desktop app's native inline visualization surface to display a comparison with four SVG device outlines, two CSS bar-chart groups, and a 19-row HTML table. The supplied content uses the host's normal visualization styles and sizing integration (.table-responsive, .table.table-sm, and theme variables).
2. Wait until that visualization has finished rendering.
3. Scroll the parent conversation up and down through the inline component.
4. Observe a large part of the lower table intermittently disappearing and returning while the rest of the app remains visually stable.
5. Repeat with the revision that removes the component's custom ResizeObserver script: the user observes the same symptom.
6. Compare with the static PNG and native Markdown table: these remain stable in the user's test.

These are the observed reproduction steps, not a claim that every newly generated table reproduces the bug. The two exact HTML fragments and the Markdown control have been retained locally. They are not a minimized test case, and an ordinary standalone browser does not supply the original native host environment. An external-browser A/B test has not been completed.

What is the expected behavior?

Scrolling a completed inline visualization should preserve the diagrams, all 19 table rows, and the existing layout/interactions without intermittent blank regions. Replacing the visualization with an image is a workaround, not a fix.

Additional information

Synchronized third capture

Capture date: 2026-09-14, Asia/Shanghai (UTC+8).

• Performance trace task coverage: approximately 19:54:18.402–19:54:46.980, corresponding to recording seconds 12.4–41.0.
• Revised inline instance visibly affected around recording seconds 18–25: guest PID 51541, frame tree node 308.
• Original inline instance visibly affected around seconds 25.4–36: guest PID 51548, frame tree node 311.
• Host renderer PID: 286.
• At recording time approximately 26.000 s, the lower table is blank; at approximately 26.100 s, several rows have returned. The amount of missing content cannot be explained by the small ordinary scroll displacement between these frames.
• Trace stop requested at 19:54:46.978; export completion logged at 19:55:06.793. The approximately 20-second wait was export time after the capture, not evidence that tracing had failed to start.

Alignment used local monotonic-clock/wall-clock calibration and trace start/stop logs. Recording metadata has whole-second creation-time precision and there is no shared hardware frame marker, so the cross-file alignment is approximate rather than frame-exact causal proof.

Trace observations and limits

The third capture contains only two Layout and one Paint events for each affected guest, while host clipping and guest visual-property/compositor activity continue during the recorded reproduction. There are partial-update and dropped-frame reporter states, but these must not be interpreted as a count of visible flickers.

The third capture's only TileBasedLayerImpl::AppendQuads checkerboard event with missing_tile_count=1 belongs to the host at timestamp 281859344957 us, mapping to approximately recording second 17.09, before the affected table is visible. It cannot explain the later recorded blanking by itself. One earlier capture had a missing-tile event in an inline guest, but it was not synchronized to a video frame; a missing-tile root cause is not established.

Important limitations: viewport geometry/transform values in the available export are represented as <value>; there are no per-frame layer snapshots. Third-capture export statistics include traced_chunks_discarded=292 and 275 trace hierarchy/parser counts. Completeness and exact geometry cannot be assumed.

Please investigate synchronization between the host clip, guest viewport/visible bounds, intrinsic height, and submitted surfaces/tiles during parent scrolling. These are investigation targets, not confirmed causes. If more data is necessary, please provide a targeted way to capture those actual rectangles/transforms and frame/layer state rather than repeating the same broad trace.

Related reports and scope

• #22860 describes generated-text flicker during streaming; a comment there mentions charts. This report adds a specific completed-component, parent-scroll blanking scenario with synchronized capture and static-content controls. A shared root cause has not been established.
• #39743 concerns jumping text/scroll position on Linux; this case is macOS and contains actual missing/returning table regions rather than only a changed scroll position.

Material availability and privacy

The exact HTML variants, Markdown control, sanitized render-event extracts, analysis notes, and a 2.2-second silent crop showing only the table are prepared locally. No attachment was uploaded with this issue: browser file selection was denied, and that restriction was not bypassed. A supported way to supply the prepared material would be useful if needed for investigation.

This public text omits account identifiers, session IDs, personal file paths, credentials, unrelated conversations, full desktop recordings, raw traces, and network requests. Only technical process/frame identifiers needed to describe the capture are included. A separate support conversation received the diagnostic summary and confirmed escalation to a support specialist; it has not confirmed engineering review or supplied an engineering tracking reference.

Start by reproducing the completed inline visualization in the macOS desktop app while scrolling the parent conversation, comparing the original and ResizeObserver-free variants with the static PNG and Markdown control. Review the synchronized performance trace and screen recording for host clipping, guest viewport bounds, intrinsic height, and submitted surfaces or tiles; done means identifying a reproducible rendering cause and a verified fix that preserves all table rows during scrolling.