Repository navigation
Expanding an HTML report shows a blank white preview in desktop app connected to remote server #25584
Description
What happened
An HTML report renders correctly inline in a conversation. Clicking “Open full screen” opens a blank white preview. Changing the zoom does not reveal the content. After closing the preview, the inline report can also become a blank white rectangle.
This happened in the macOS desktop app connected to a remote server.
Diagnosis
The cause is unconfirmed.
The remote report attachment exists and contains HTML and table content. The remote server trace contains no failed spans during the recording window, approximately 2026-10-26 17:19–17:21 UTC.
In release v0.1.2:
HtmlRenderFrame.tsxopens the expanded view using a signed attachment URL.HtmlRenderDialog.tsxmounts a separateHtmlRenderDocumentiframe.BrowserDocumentFrame.tsxhas no visible error reporting for a failed iframe load.
These observations identify the affected code path but do not establish whether the failure involves loading, URL expiry, or rendering.
Steps to reproduce
Observed in the affected conversation; not independently reproduced in a fresh conversation.
- Open the desktop app connected to a remote T3 Code server.
- Open a conversation containing an inline HTML report.
- Confirm that the report displays correctly inline.
- Click “Open full screen.”
- Observe a blank white preview.
- Change zoom. The preview remains blank.
- Close the preview. The inline report can also appear blank.
Version
Desktop app: 0.1.2
Remote server: 0.1.2
Triage CLI: 0.1.2
Environment
- Client: macOS, Darwin 25.6.0, ARM64
- Remote server: Ubuntu 24.04.4 LTS, x86-64
- Connection: desktop app to remote server
Evidence
A 26-second screen recording showed the report rendering inline, the expanded preview remaining white at different zoom levels, and a blank inline report afterward.
The report attachment was present and approximately 18.9 KB, with HTML and table elements. No failed server trace spans were found in the inspected time window.
The recording and extracted frames were deleted at the user’s request.
Related issues
No confirmed duplicate found.
PR #24970 changes HTML frame asset URL refresh handling and was merged after 0.1.2. Its relevance to this failure is unconfirmed.
Fix applied or workaround
No fix applied. No source, database, or configuration changes were made.
Filed by
GPT 6.1 sol using t3 triage
Activity
dkritarth commentedon Oct 26, 2026
Screen recording showing the HTML preview failure in the desktop app connected to the remote server. The report renders inline, but the expanded preview is blank and remains blank when zoom changes.
t3-25584-recording.mp4
Recorded on version 0.1.2. Compressed for upload.
juliusmarminge commentedon Oct 27, 2026
Tried to reproduce on main at 96fc7b9 with a synthetic 40-row HTML table report served from a different origin than the app, like a remote server:
HtmlRenderFrameand full-screen dialog in Chromium: the expanded frame loads and reports its content height, and the inline frame survives closing.None of these reproduced it. In your recording, the white area also covers the space around the expanded preview, and after closing it covers most of the chat pane while the sidebar still draws. That looks like the window stops painting, not like the report failing to load.
To narrow it down, could you share:
/api/assets/…request in the Network tab.juliusmarminge commentedon Nov 12, 2026
@dkritarth Does it happen again after you quit and reopen the app and open a report in a new thread? If so, when it goes white, open View → Toggle Developer Tools: what do the Console errors say, and what status does the
/api/assets/…request show in the Network tab?dkritarth commentedon Nov 12, 2026
Note
🤖 GPT-6.1 SOL responding on behalf of @dkritarth
@juliusmarminge Sorry for missing your earlier message. I hadn't realized you had already asked for these details.
I reviewed the recording and located the original thread and HTML report. There is another symptom worth clarifying: the report contains
t3-thread://v1/...links. At the time, I also wrote in that thread: "I am unable to click the thread links in the HTML render, and it does not show up in t3code." My suspicion is that these links were opening through a browser without routing back to the correct running T3 Code instance. That is a hypothesis, not a confirmed explanation for the white preview.Today's retest used the original report in the browser UI on macOS, connected to the same remote server through an SSH tunnel, with server version 0.1.9:
/api/assets/…URL in that browser returned HTTP 200 and HTML containing the report table.t3-thread://v1/...link in the expanded report did not navigate the T3 page to the target thread. The report remained displayed.The Mac is a MacBook Air with Apple M2 graphics and 16 GB RAM. A Dell P2417H external display is connected today; the display and native-fullscreen state during the original recording are unverified.
I haven't completed the specific quit/reopen desktop-app test with a report in a new thread. Native UI automation was blocked by macOS Accessibility permissions, so the browser results above should not be taken as a successful desktop retest or a fix. The desktop app currently reports 0.1.9; the original recording was on 0.1.2. I don't have Console errors or an asset-request status captured during the original white-screen failure.
dkritarth commentedon Nov 12, 2026
Btw just checked manually (instead of telling the LLM to check it). It is still happening, my hypothesis is still, since the links in the html page were t3 thread links to the other threads on other machines, when it is clicked, instead of it opening in my t3 code it opens in the browser used for the html preview and hence the page becomes white.
Again not really a good software engineer, but more of a researcher. But that is my conclusions from the debugging.
When I ask the model to give me the links in the chat it works since the t3 code links now pull up those t2 code threads which I have.
Again really appreciate the work you guys put into this.
juliusmarminge commentedon Nov 12, 2026
This is the same problem as #27474, so I'm closing it in favour of that one. If it is different, say how and it will be reopened.