.CYuT_dZX_1uGpNi.svg){kind=small}
.Bf10y01t_PVSYK.svg){kind=small}
.Cghii_pL_Z1DYVxU.svg){kind=small}
.CbeacWq7_1cxFXE.svg){kind=small}
.D2k-3zqT_Z10D5qc.svg){kind=small}
.C_Hn_1GY_NRL3p.svg){kind=small}
TimeoutError: waiting for selector at step 14 of 20
Sessions are free — pay only for traffic
Cloud Browser with UI Mode
Open that exact session in a real browser tab and just look at it. Whatever state the page is sitting in when things went sideways, that's what you see.
- Open a live view of a running session instead of rerunning the job to reproduce the failure
- Hand a hard CAPTCHA or an unexpected 2FA prompt to a person, then let the script reconnect
- Cookies and page state stay put — only the connection changes
UI Mode
Open the session
in a real browser.
Any running session can be opened in a live view: the same browser the script was driving, in a tab of your own. Click through what it can't, then hand it back.
Why UI Mode Matters in a Cloud Browser
A headless script that breaks somewhere in the middle usually just hands you a stack trace. Maybe a line number. Good luck figuring out which click actually missed on step fourteen of twenty, or whether the page even loaded the way it was supposed to.
Cloud Browser with UI Mode gives you a second option: open that exact session in a real browser tab and just look at it. Whatever state the page is sitting in when things went sideways, that's what you see – no piecing it together from console output afterward, no rerunning the whole job five times hoping for a clearer error message.
This tends to matter most on logins with extra steps, forms that change depending on earlier answers, checkout flows. Basically anywhere a stray popup can quietly break a script that was working fine an hour earlier, and nobody wrote a rule for that specific popup because nobody expected it.
Key Features of the Visual Mode
Live view covers a few different jobs depending on why you actually need it. Sometimes it's about catching a bug, sometimes it's about getting past one.
Real-Time Script Debugging (Live Debugging)
A stalled or failed run doesn't usually mean the session died. It's often still sitting there, just disconnected from anything. Open a live view and you're looking straight at it, mid-failure, rather than guessing from a log file what the page probably looked like at that point.
This also catches problems that never throw a clean error at all – a page that half-loaded, a layout shift that pushed a button out from under a click, a modal that popped up half a second too late.
Interactive Session Control (Human-in-the-Loop)
Certain things a script just can't push through on its own – a hard CAPTCHA, an unexpected 2FA prompt, some security check nobody planned for. When that happens, the automation connection drops, a live view opens for the same session, and someone clicks through the annoying part by hand.
After that, the script reconnects and keeps going from there. Cookies, page state, everything stays put – only the connection changed. This matters just as much on sessions running through an antidetect setup: an anti-detect browser with an otherwise convincing, undetectable fingerprint can still land on a check that only a real person can clear.
Session Recording and Screenshots
Watching a session live only helps if you're there when it happens. Most debugging eventually needs something to look at afterward – a screenshot from the moment things broke, a full session recording, a network log to check what actually got sent and received.
Not every cloud browser platform ships all three the same way, so it's worth checking directly with Floppydata on what's supported before building a workflow around a specific format. A screenshot from right before the failure is often enough on its own; video and network logs earn their keep on the harder cases where nothing visual explains what went wrong.
Where This Actually Gets Used
A few situations come up again and again, and they don't always look alike on the surface:
-
Sign-up flows and checkout fraud checks
Sign-up flows behind SMS verification, or checkout pages that occasionally trigger a fraud check – annoying to script around, quick to click through once.
-
Telling a real bug from a flaky selector
QA teams checking whether a failed end-to-end test is a real bug or just a flaky selector, instead of rerunning the whole suite blind.
-
Reproducing what a customer described
Support teams reproducing a bug a customer described but couldn't screenshot properly.
-
Confirming the page rendered as expected
Scraping jobs confirming a page actually rendered the way a selector expects, before assuming the selector itself is broken.
-
Showing it working live
Client demos, where showing something working live beats asking someone to trust a terminal log.
How to Enable UI / Live Viewer in Your Script
A session can't run an automation connection and a live view at the same time. Closing one opens the door to the other, and switching back afterward takes about as long as it took to switch away:
- The script disconnects from its current session.
- A live view is requested for that same session and opened in a browser tab.
- A person handles whatever needs handling – a CAPTCHA, a 2FA code, a one-off consent screen.
- The script asks for a fresh connection to the session and picks up right where it left off.
live-view.js
await browser.close(); // hand off to a human// POST /v2/browser/sessions/{id}/live-view -> { liveViewUrl }// person opens liveViewUrl, solves the CAPTCHA / 2FA prompt// GET /v2/browser/sessions/{id} -> fresh connectUrl, script resumesBoth connectUrl and liveViewUrl should be handled like passwords: don't log them anywhere, don't paste them into a support ticket, and request a new one instead of hanging onto an old link longer than you need to.