[Bug]: preview_resize returns inconsistent viewport state for desktop tabs#22943
Written by human: IMO, this is a relatively unimportant, low-priority bug. I split it off from 3712 by request (https://github.com/pingdotgg/t3code/issues/3712#issuecomment-6314977935).
Written by an agent:
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/server
Steps to reproduce
Run T3 Code Desktop with a Codex thread and browser access enabled. Serve a static HTML page over local HTTP.
Open a fresh desktop-backed preview tab:
js1 preview_open({ 2 url: "http://127.0.0.1:8741/index.html", 3 profileId: "incognito", 4 reuseExistingTab: false, 5 open: true, 6 show: true 7 }) Use the actual URL of the local page and retain the returned tab ID.
Resize that tab:
js1 preview_resize({ 2 tabId, 3 mode: "freeform", 4 width: 1920, 5 height: 1200, 6 timeoutMs: 15000 7 }) Read its actual CSS viewport:
js1 preview_evaluate({ 2 tabId, 3 expression: "({width:innerWidth,height:innerHeight,dpr:devicePixelRatio})" 4 }) Call
preview_status({tabId}).Repeat using:
js1 preview_resize({ 2 tabId, 3 mode: "preset", 4 preset: "iphone-12-pro", 5 orientation: "portrait" 6 })
Expected behavior
Resize returns the effective viewport of the targeted desktop tab. Status reports measured dimensions separately from the requested setting.
If the requested size has not taken effect, the result should make that clear rather than reporting successful completion with fallback dimensions.
Actual behavior
Both requests succeed, but the returned viewport is always 1280×800:
| Requested setting | Resize response viewport | Live CSS viewport |
|---|---|---|
| 1920×1200 freeform | 1280×800 | 1920×1200 |
| 390×844 iPhone preset | 1280×800 | 390×844 |
| 560×760 freeform | 1280×800 | 560×760 |
preview_status records the requested viewportSetting but omits the measured viewport.
There was also a more substantial mismatch on a second tab initially opened with open:false: repeated 844×390 preset requests returned success and updated the stored setting, while the live DOM remained 560×760. This persisted across later reads and revealing the tab. That sequence included snapshot timeouts and has not been minimized, so it does not establish that both symptoms have the same cause.
No resize request timed out in this retest.
Impact
Minor bug or occasional failure
Version or commit
main @ 680152e27b2a961686389ca69a1557cbb2c55f08
Environment
Linux x86_64; Electron 44.9.3; Chromium 152.0.7977.167; page DPR 2; Codex provider through T3 Code.
Logs or stack traces
| 1 | Representative resize response, omitting tab ID and site-icon metadata: |
| 2 | |
| 3 | |
| 4 | { |
| 5 | "setting": {"_tag":"freeform","width":1920,"height":1200}, |
| 6 | "viewport": {"width":1280,"height":800} |
| 7 | } |
| 8 | |
| 9 | |
| 10 | Live evaluation immediately afterward: |
| 11 | |
| 12 | |
| 13 | {"width":1920,"height":1200,"dpr":2} |
| 14 | |
| 15 | |
| 16 | Source observations at the tested commit: |
| 17 | |
| 18 | - `ServerBrowser.ts` skips `page.setViewportSize` for desktop-rendered tabs in `applySetting`. |
| 19 | - Resize returns `page.viewportSize() ?? UNATTACHED_FILL_VIEWPORT`. |
| 20 | - Status uses `page.viewportSize()` and omits `viewport` when that value is absent. |
| 21 | |
| 22 | https://github.com/pingdotgg/t3code/blob/680152e27b2a961686389ca69a1557cbb2c55f08/apps/server/src/preview/ServerBrowser.ts#L632 |
Screenshots, recordings, or supporting files
No response
Workaround
Read innerWidth and innerHeight through preview_evaluate. This detects a failed resize; it does not make the requested size take effect.
Related issues
Focused follow-up requested in the closing comment on #3712: https://github.com/pingdotgg/t3code/issues/3712#issuecomment-6314977935
#10525 concerned a zoom-dependent multiplier and was closed after #14039. This retest instead shows fallback metadata and, on one tab, an unapplied setting.
Investigated and drafted by GPT-6.1-Sol through the Codex harness in T3 Code.