.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 bei Schritt 14 von 20
Sitzungen sind kostenlos – Sie zahlen nur für Traffic
Cloud-Browser mit UI-Modus
Öffnen Sie genau diese Sitzung in einem echten Browser-Tab und sehen Sie einfach hin. In welchem Zustand sich die Seite befand, als etwas schiefging – genau das sehen Sie.
- Eine Live-Ansicht der laufenden Sitzung öffnen, statt den Job erneut auszuführen, um den Fehler zu reproduzieren
- Ein schwieriges CAPTCHA oder eine unerwartete 2FA-Abfrage an einen Menschen übergeben und das Skript anschließend wieder verbinden lassen
- Cookies und Seitenzustand bleiben erhalten – nur die Verbindung wechselt
UI-Modus
Öffnen Sie die Sitzung
in einem echten Browser.
Jede laufende Sitzung lässt sich in einer Live-Ansicht öffnen: derselbe Browser, den das Skript gesteuert hat, in einem eigenen Tab. Klicken Sie sich durch, was das Skript nicht schafft, und geben Sie dann die Kontrolle zurück.
Warum der UI-Modus in einem Cloud-Browser wichtig ist
Ein Headless-Skript, das mittendrin abbricht, liefert Ihnen meist nur einen Stacktrace. Vielleicht noch eine Zeilennummer. Viel Glück dabei, herauszufinden, welcher Klick in Schritt vierzehn von zwanzig danebenging – oder ob die Seite überhaupt so geladen wurde, wie sie sollte.
Der Cloud-Browser mit UI-Modus bietet Ihnen eine zweite Möglichkeit: Öffnen Sie genau diese Sitzung in einem echten Browser-Tab und sehen Sie einfach hin. In welchem Zustand sich die Seite befand, als etwas schiefging, genau das sehen Sie – ohne es hinterher aus der Konsolenausgabe zusammenzupuzzeln und ohne den ganzen Job fünfmal neu zu starten, in der Hoffnung auf eine klarere Fehlermeldung.
Besonders wichtig ist das bei Logins mit Zwischenschritten, bei Formularen, die sich je nach vorherigen Antworten ändern, und bei Checkout-Abläufen. Im Grunde überall dort, wo ein verirrtes Popup ein Skript, das eine Stunde zuvor noch einwandfrei lief, still und leise lahmlegen kann – und niemand eine Regel für genau dieses Popup geschrieben hat, weil niemand damit gerechnet hat.
Wichtige Funktionen des visuellen Modus
Die Live-Ansicht deckt je nach Anlass unterschiedliche Aufgaben ab. Manchmal geht es darum, einen Fehler zu finden, manchmal darum, an ihm vorbeizukommen.
Skript-Debugging in Echtzeit (Live-Debugging)
Ein hängender oder fehlgeschlagener Lauf bedeutet meist nicht, dass die Sitzung beendet ist. Oft besteht sie weiter, nur ohne Verbindung zu irgendetwas. Wenn Sie eine Live-Ansicht öffnen, haben Sie sie direkt vor Augen – mitten im Fehlerzustand –, statt aus einer Logdatei zu erraten, wie die Seite an dieser Stelle wohl aussah.
So fallen auch Probleme auf, die nie einen sauberen Fehler auslösen – eine halb geladene Seite, ein Layout-Sprung, der einen Button unter dem Klick wegschiebt, ein Modal, das eine halbe Sekunde zu spät erscheint.
Interaktive Sitzungssteuerung (Human-in-the-Loop)
Manches schafft ein Skript allein einfach nicht – ein schwieriges CAPTCHA, eine unerwartete 2FA-Abfrage, eine Sicherheitsprüfung, die niemand eingeplant hat. Dann wird die Automatisierungsverbindung getrennt, für dieselbe Sitzung öffnet sich eine Live-Ansicht, und jemand klickt sich von Hand durch den lästigen Teil.
Danach verbindet sich das Skript neu und macht dort weiter. Cookies, Seitenzustand, alles bleibt erhalten – nur die Verbindung hat gewechselt. Das ist bei Sitzungen über ein Antidetect-Setup genauso wichtig: Ein Antidetect-Browser mit einem ansonsten überzeugenden, nicht erkennbaren Fingerprint kann trotzdem auf eine Prüfung stoßen, die nur ein echter Mensch bestehen kann.
Sitzungsaufzeichnung und Screenshots
Eine Sitzung live zu verfolgen hilft nur, wenn Sie gerade dabei sind. Beim Debugging braucht man meist irgendwann etwas zum Nachsehen – einen Screenshot vom Moment des Fehlers, eine vollständige Sitzungsaufzeichnung, ein Netzwerkprotokoll, um zu prüfen, was tatsächlich gesendet und empfangen wurde.
Nicht jede Cloud-Browser-Plattform bietet alle drei auf dieselbe Weise an. Fragen Sie daher direkt bei Floppydata nach, was unterstützt wird, bevor Sie einen Workflow auf ein bestimmtes Format aufbauen. Ein Screenshot kurz vor dem Fehler reicht oft schon aus; Video und Netzwerkprotokolle zahlen sich bei den schwierigeren Fällen aus, in denen nichts Visuelles erklärt, was schiefgelaufen ist.
Wo das tatsächlich zum Einsatz kommt
Einige Situationen tauchen immer wieder auf, und sie sehen oberflächlich nicht immer gleich aus:
-
Registrierungsabläufe und Betrugsprüfungen beim Checkout
Registrierungsabläufe hinter einer SMS-Verifizierung oder Checkout-Seiten, die gelegentlich eine Betrugsprüfung auslösen – per Skript lästig zu umgehen, von Hand schnell durchgeklickt.
-
Einen echten Bug von einem instabilen Selektor unterscheiden
QA-Teams prüfen, ob ein fehlgeschlagener End-to-End-Test ein echter Bug oder nur ein instabiler Selektor ist, statt blind die ganze Test-Suite neu zu starten.
-
Nachstellen, was ein Kunde beschrieben hat
Support-Teams stellen einen Fehler nach, den ein Kunde beschrieben, aber nicht richtig per Screenshot festgehalten hat.
-
Prüfen, ob die Seite wie erwartet gerendert wurde
Scraping-Jobs prüfen, ob eine Seite tatsächlich so gerendert wurde, wie ein Selektor es erwartet, bevor sie annehmen, der Selektor selbst sei defekt.
-
Live zeigen, dass es funktioniert
Kundendemos, bei denen es mehr überzeugt, etwas live funktionieren zu sehen, als jemanden zu bitten, einem Terminal-Log zu vertrauen.
So aktivieren Sie den UI-Modus / die Live-Ansicht in Ihrem Skript
Eine Sitzung kann nicht gleichzeitig eine Automatisierungsverbindung und eine Live-Ansicht haben. Wird die eine geschlossen, öffnet sich die Tür für die andere, und der Rückwechsel dauert ungefähr so lange wie der ursprüngliche Wechsel:
- Das Skript trennt die Verbindung zu seiner aktuellen Sitzung.
- Für dieselbe Sitzung wird eine Live-Ansicht angefordert und in einem Browser-Tab geöffnet.
- Eine Person erledigt, was zu erledigen ist – ein CAPTCHA, einen 2FA-Code, einen einmaligen Einwilligungsdialog.
- Das Skript fordert eine neue Verbindung zur Sitzung an und macht genau dort weiter, wo es aufgehört hat.
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 resumesconnectUrl und liveViewUrl sollten beide wie Passwörter behandelt werden: Protokollieren Sie sie nirgends, fügen Sie sie nicht in ein Support-Ticket ein und fordern Sie lieber einen neuen Link an, statt einen alten länger als nötig aufzubewahren.