[Bug]: Element picker drops screenshot after five-second capture timeout

[gabrielMalonso]

Before submitting

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

Area

apps/desktop

Steps to reproduce

1. Open T3 Code Desktop Nightly and show a local web app in the browser preview (in this case http://localhost:5173/).
2. Start the element picker.
3. Select an element in the page.
4. Enter an annotation and click Attach.

Expected behavior

The annotation and a cropped screenshot of the selected element should be added to the composer.

Actual behavior

The structured annotation is added, but its screenshot is consistently dropped. T3 Code shows:

Could not capture the picked element
The annotation was kept without the screenshot.

The page remains loaded and interactive in the visible preview.

Impact

Major degradation or frequent failure

Version or commit

T3 Code Desktop 0.0.39-nightly.20260906.1293

Environment

macOS 27.0 (26A5425a), Apple Silicon arm64, visible embedded browser preview, local Vite page

Logs or stack traces

The desktop trace records PreviewManager.pickElement as successful even when the screenshot is dropped. Representative durations from repeated attempts:

PreviewManager.pickElement durationMs=5952.872833 exit=Success
PreviewManager.pickElement durationMs=5146.751917 exit=Success
PreviewManager.pickElement durationMs=6606.606333 exit=Success

These durations line up with ANNOTATION_SCREENSHOT_TIMEOUT = "5 seconds" in apps/desktop/src/preview/Manager.ts. The underlying webContents.capturePage() failure/timeout is collapsed into screenshotFailed: true, while the detached warning (preview annotation screenshot timed out) does not appear in desktop.trace.ndjson. As a result, the trace confirms the delayed pick but does not preserve the precise capture failure.

This started after a recent Nightly update. Commit 19c97ea56 added the five-second timeout and user-visible fallback for a wedged guest compositor, but the annotation screenshot now fails repeatedly in this otherwise responsive visible tab.

Screenshots, recordings, or supporting files

Selected element remains visible and responsive after the crop is dropped:

Error toast shown after clicking Attach:

Workaround

Take a separate screenshot and attach it manually. The structured element annotation still works without the crop.

Related issues

• [Bug]: preview_snapshot can fail or time out on loaded pages and leave tab automation unusable #3713 tracks preview automation snapshot failures, but not manual element-picker screenshot attachments.
• [Bug]: Leaving a thread detaches its browser preview and can leave automation unusable #6355 tracks a preview becoming unusable after thread detachment; in this case the visible preview remains responsive.

[juliusmarminge]

Thanks for the tight repro and traces — this looks like a real regression, not a duplicate of the old hang.

What we think is happening

#9127 (19c97ea56) fixed #9026 by bounding a wedged webContents.capturePage() at 5 seconds and keeping the annotation without the crop. That path is:

• apps/desktop/src/preview/Manager.ts — captureAnnotationScreenshot() / ANNOTATION_SCREENSHOT_TIMEOUT = "5 seconds"
• result collapsed to screenshotFailed: true so PreviewManager.pickElement still exits Success
• apps/web/src/components/preview/PreviewView.tsx — the exact toast you saw

Your pickElement durations (5.1–6.6s) line up with that timeout after a short pick + Attach. The fallback is working as designed; it is now firing on a visible, interactive tab, which #9127 already flagged as a risk (“legitimate crops slower than 5s may arrive without a screenshot”).

This is not:

• a wash duplicate of closed [Bug]: Sending a picked preview element hangs on "Capturing..." forever and locks the composer #9026 (that was hang-forever on Capturing…; the composer unlock is the part that still works)
• [Bug]: preview annotation element picker does not work inside iframes #3141 (iframes)
• [Bug]: preview_snapshot can fail or time out on loaded pages and leave tab automation unusable #3713 (automation preview_snapshot)
• [Bug]: Leaving a thread detaches its browser preview and can leave automation unusable #6355 (preview poisoned after thread detach)

Why the trace is unhelpful

Annotation capture is a single wc.capturePage(cropRect) with no retry and no named span. Automation and the screenshot button go through capturePageWithRetry (3 × 1s) and a full-page capturePage(). The warning preview annotation screenshot timed out is logged from a forked callback that does not inherit the pickElement span, so it can miss desktop.trace.ndjson even when the crop is dropped.

Next step for a fix

Reproduce on Nightly with a visible local Vite preview and determine whether capturePage(rect) is merely slower than 5s or never settles. Then:

1. Reuse capturePageWithRetry, raise the annotation timeout, or capture the full page and crop in-process.
2. Give captureAnnotationScreenshot a named span (timeout vs error vs success) so traces show the actual failure.

Useful extra signal if you have it: does the normal preview screenshot button still attach an image on the same tab? That would tell us whether only the cropped annotation path is stuck.

Workaround you already have is the right one: keep the structured annotation and attach a manual screenshot.

Triage: bug / regression, major, apps/desktop element-picker crop. Accepting.

[gabrielMalonso]

Confirmed: the normal preview screenshot button still works on the same tab. It saves the full screenshot successfully, and Copy image also puts the image on the clipboard correctly.

This appears isolated to the element picker's cropped capturePage(rect) path rather than preview capture in general.