.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 людині, а потім дозвольте скрипту перепідключитися
- Cookies і стан сторінки залишаються на місці — змінюється лише підключення
Режим інтерфейсу
Відкрийте сесію
у справжньому браузері.
Будь-яку запущену сесію можна відкрити в живому перегляді: той самий браузер, яким керував скрипт, у вашій власній вкладці. Пройдіть те, з чим він не впорався, а потім поверніть керування.
Чому UI-режим важливий у хмарному браузері
Headless-скрипт, який ламається десь посередині, зазвичай видає лише стек викликів. А може, ще й номер рядка. Успіхів у спробах зрозуміти, який саме клік схибив на чотирнадцятому кроці з двадцяти, або хоча б те, чи завантажилася сторінка так, як мала.
Хмарний браузер з UI-режимом дає вам другий варіант: відкрити саме цю сесію у вкладці справжнього браузера й просто подивитися на неї. У якому б стані не була сторінка, коли щось пішло не так, ви побачите саме його – без складання картини з виводу консолі постфактум і без п’яти перезапусків усього завдання в надії на зрозумілішу помилку.
Найбільше це важливо для входу з додатковими кроками, форм, що змінюються залежно від попередніх відповідей, і сценаріїв оформлення замовлення. Тобто всюди, де випадковий попап може тихо зламати скрипт, який годину тому працював нормально, а правила для саме цього попапа ніхто не написав, бо ніхто його не очікував.
Ключові можливості візуального режиму
Живий перегляд вирішує кілька різних завдань залежно від того, навіщо він вам потрібен. Іноді це про те, щоб упіймати помилку, іноді — щоб її обійти.
Налагодження скриптів у реальному часі (живе налагодження)
Завислий або невдалий запуск зазвичай не означає, що сесія «померла». Часто вона все ще на місці, просто ні до чого не підключена. Відкрийте живий перегляд — і ви дивитеся прямо на неї в момент збою, а не гадаєте за лог-файлом, як могла виглядати сторінка на той момент.
Так можна впіймати і проблеми, які взагалі не видають чіткої помилки: сторінку, що завантажилась наполовину, зсув макета, через який кнопка вислизнула з-під кліка, або модальне вікно, що з’явилося на пів секунди запізно.
Інтерактивне керування сесією (Human-in-the-Loop)
Дещо скрипт просто не може пройти самостійно: складну CAPTCHA, несподіваний запит 2FA, якусь перевірку безпеки, яку ніхто не передбачав. Тоді підключення автоматизації розривається, для тієї самої сесії відкривається живий перегляд, і хтось проходить неприємну ділянку вручну.
Після цього скрипт перепідключається й продовжує з того самого місця. Cookies, стан сторінки, усе залишається на місці – змінилося лише підключення. Це так само важливо для сесій, що працюють через антидетект-налаштування: антидетект-браузер з цілком переконливим, невиявним фінгерпринтом усе одно може натрапити на перевірку, яку здатна пройти лише справжня людина.
Запис сесій і скриншоти
Спостереження за сесією наживо допомагає, лише якщо ви поруч саме тоді, коли все відбувається. Для більшості налагоджень згодом потрібно щось, що можна переглянути постфактум: скриншот із моменту збою, повний запис сесії, мережевий лог, щоб перевірити, що саме було надіслано й отримано.
Не кожна платформа хмарного браузера надає всі три можливості однаково, тож перш ніж будувати робочий процес навколо конкретного формату, варто уточнити у Floppydata, що саме підтримується. Скриншота за мить до збою часто достатньо самого по собі; відео та мережеві логи виправдовують себе у складніших випадках, коли жодна візуальна ознака не пояснює, що пішло не так.
Де це справді використовують
Кілька ситуацій трапляються знову і знову, і на перший погляд вони не завжди схожі:
-
Реєстрація та антишахрайські перевірки під час оформлення замовлення
Реєстрація із SMS-верифікацією або сторінки оформлення замовлення, що іноді запускають антишахрайську перевірку: скриптом обходити їх морока, а вручну пройти один раз — швидко.
-
Відрізнити справжній баг від нестабільного селектора
QA-команди перевіряють, чи невдалий наскрізний тест — це справжній баг чи просто нестабільний селектор, замість того щоб наосліп перезапускати весь набір тестів.
-
Відтворення того, що описав клієнт
Команди підтримки відтворюють баг, який клієнт описав, але не зміг нормально зафіксувати на скриншоті.
-
Перевірка, що сторінка відрендерилась як очікувалось
Завдання зі скрапінгу перевіряють, чи сторінка справді відрендерилась так, як очікує селектор, перш ніж вважати, що зламаний сам селектор.
-
Демонстрація роботи наживо
Демо для клієнтів, де показати, як щось працює наживо, краще, ніж просити повірити логу в терміналі.
Як увімкнути UI / живий перегляд у вашому скрипті
Сесія не може одночасно мати підключення автоматизації та живий перегляд. Закриття одного відкриває шлях до іншого, а повернення назад займає приблизно стільки ж часу, скільки й перемикання:
- Скрипт від’єднується від поточної сесії.
- Для тієї самої сесії запитується живий перегляд і відкривається у вкладці браузера.
- Людина виконує все, що потребує ручної дії: 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 слід поводитися як з паролями: не записуйте їх у логи, не вставляйте в тікет підтримки та запитуйте нове посилання замість того, щоб зберігати старе довше, ніж потрібно.