.4UVmK5aw_1uGpNi.svg){kind=small}
.AzQB9McO_PVSYK.svg){kind=small}
.DjhlE8MO_Z1DYVxU.svg){kind=small}
.DM2pllEO_1cxFXE.svg){kind=small}
.CvN5042A_Z10D5qc.svg){kind=small}
.Dcqs_gC__NRL3p.svg){kind=small}
TimeoutError: waiting for selector на шаге 14 из 20
Сессии бесплатны — платите только за трафик
Облачный браузер с UI-режимом
Откройте именно эту сессию во вкладке настоящего браузера и просто посмотрите на неё. В каком бы состоянии ни была страница, когда что-то пошло не так, вы увидите именно его.
- Откройте живой просмотр запущенной сессии вместо того, чтобы перезапускать задачу ради воспроизведения сбоя
- Передайте сложную CAPTCHA или неожиданный запрос 2FA человеку, а затем позвольте скрипту подключиться снова
- Cookie и состояние страницы сохраняются — меняется только подключение
Режим интерфейса
Откройте сессию
в настоящем браузере.
Любую запущенную сессию можно открыть в живом просмотре: тот же браузер, которым управлял скрипт, в вашей собственной вкладке. Пройдите вручную то, что не под силу скрипту, а затем верните управление ему.
Зачем нужен UI-режим в облачном браузере
Headless-скрипт, который падает где-то посередине, обычно выдаёт лишь трассировку стека. Ну, может, ещё номер строки. Попробуйте-ка понять, какой именно клик промахнулся на четырнадцатом шаге из двадцати и загрузилась ли страница вообще так, как должна.
Облачный браузер с UI-режимом даёт второй вариант: откройте именно эту сессию во вкладке настоящего браузера и просто посмотрите на неё. В каком бы состоянии ни была страница, когда что-то пошло не так, вы увидите именно его — без восстановления картины по выводу консоли и без пятикратного перезапуска всей задачи в надежде получить более понятное сообщение об ошибке.
Чаще всего это важно при входе с дополнительными шагами, в формах, которые меняются в зависимости от предыдущих ответов, и в процессах оформления заказа. По сути, везде, где случайное всплывающее окно может незаметно сломать скрипт, отлично работавший час назад, а правила для этого конкретного окна никто не писал, потому что никто его не ждал.
Ключевые возможности визуального режима
Живой просмотр решает разные задачи в зависимости от того, зачем он вам нужен. Иногда нужно поймать ошибку, а иногда — обойти препятствие.
Отладка скриптов в реальном времени (Live Debugging)
Зависший или завершившийся ошибкой запуск обычно не означает, что сессия умерла. Часто она всё ещё существует, просто ни к чему не подключена. Откройте живой просмотр, и вы увидите её прямо в момент сбоя, а не будете гадать по лог-файлу, как выглядела страница.
Так можно поймать и проблемы, которые вообще не выдают внятной ошибки: наполовину загруженную страницу, сдвиг вёрстки, из-за которого кнопка ушла из-под клика, модальное окно, появившееся на полсекунды позже.
Интерактивное управление сессией (участие человека)
Кое-что скрипт просто не может пройти самостоятельно: сложную CAPTCHA, неожиданный запрос 2FA, непредвиденную проверку безопасности. В таком случае подключение автоматизации разрывается, для той же сессии открывается живой просмотр, и кто-то вручную проходит неудобный участок.
После этого скрипт подключается снова и продолжает работу с того же места. Cookie, состояние страницы — всё сохраняется, меняется только подключение. Это не менее важно для сессий, работающих через антидетект-решения: даже антидетект-браузер с убедительным, неотличимым от настоящего отпечатком может наткнуться на проверку, которую пройдёт только живой человек.
Запись сессий и скриншоты
Наблюдать за сессией вживую можно, только если вы рядом в нужный момент. Для отладки обычно нужно что-то, что можно изучить потом: скриншот момента сбоя, полная запись сессии, сетевой лог, показывающий, что на самом деле отправлялось и приходило.
Не все платформы облачных браузеров предлагают все три варианта одинаково, поэтому перед созданием рабочего процесса под конкретный формат стоит уточнить у Floppydata, что именно поддерживается. Часто хватает одного скриншота перед сбоем; видео и сетевые логи окупаются в сложных случаях, когда визуально причину понять невозможно.
Где это действительно применяется
Несколько ситуаций встречаются снова и снова, и внешне они не всегда похожи:
-
Регистрация и антифрод-проверки при оформлении заказа
Регистрация с SMS-подтверждением или страницы оформления заказа, которые время от времени запускают антифрод-проверку: обходить их скриптом неудобно, а вручную пройти один раз быстро.
-
Отличить настоящий баг от нестабильного селектора
QA-команды проверяют, что стоит за упавшим сквозным тестом — настоящий баг или просто нестабильный селектор, вместо слепого перезапуска всего набора тестов.
-
Воспроизведение проблемы, описанной клиентом
Команды поддержки воспроизводят баг, который клиент описал, но не смог нормально заснять на скриншот.
-
Проверка корректного рендеринга страницы
Задачи парсинга проверяют, что страница отрисовалась так, как ожидает селектор, прежде чем считать сломанным сам селектор.
-
Демонстрация работы вживую
Демо для клиентов, где показать работу вживую убедительнее, чем просить поверить логу в терминале.
Как включить UI / Live Viewer в вашем скрипте
Сессия не может одновременно поддерживать подключение автоматизации и живой просмотр. Закрыв одно, вы открываете другое, а переключение обратно занимает столько же времени, сколько и переключение туда:
- Скрипт отключается от текущей сессии.
- Для этой же сессии запрашивается живой просмотр, и он открывается во вкладке браузера.
- Человек делает всё, что требуется: проходит CAPTCHA, вводит код 2FA, закрывает разовый экран согласия.
- Скрипт запрашивает новое подключение к сессии и продолжает ровно с того места, где остановился.
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 resumesИ connectUrl, и liveViewUrl нужно беречь как пароли: не записывайте их в логи, не вставляйте в обращения в поддержку и запрашивайте новую ссылку, а не храните старую дольше необходимого.