Elements: prüfen und live ändern
Der lebende DOM-Baum der Seite mit berechneten Stilen, Vererbung und Box-Modell. Einen Wert ändern und das Gerät zeichnet sofort neu — der schnellste Weg zu einem mobilen Layout-Bug.
Webseiten auf dem Handy vom Rechner aus debuggen
Wie F12 im eigenen Browser — nur für Seiten, die auf einem echten iOS- oder Android-Gerät laufen: Browser-Tabs oder das WebView / H5 in einer App. Elemente prüfen, Konsolenfehler lesen, Breakpoints setzen, Netzwerk-Requests verfolgen, Cookies und Local Storage öffnen.
- Requests aus App-WebViews
- Requests des Handy-Browsers
- Gerätebild neben den Panels
- Ohne App-Rebuild
Mobiles Web-Debugging ohne den üblichen Umweg
Alles unten ist ganz normaler Alltag beim Debuggen einer Seite auf dem Handy. Links steht, wie es sonst läuft.
| Was Sie vorhaben | Der übliche Weg | Mit dem Web-Inspector |
|---|---|---|
| Das Layout bricht nur auf dem Handy | Fix raten, neu bauen, deployen, wieder hinschauen | Element und CSS live ändern und zusehen, wie das Gerät sofort neu zeichnet |
| Weiße Seite oder ein Button tut nichts | Auf dem Handy gibt es keine Konsole, also Alerts und Logs einbauen | Konsolenfehler und Logs genau so, wie die Seite sie geworfen hat |
| Herausfinden, welche JavaScript-Zeile eine Anfrage ausgelöst hat | Ein Mitschnitt zeigt die Anfrage, nie den Aufrufer | Breakpoints und Einzelschritte in Sources, samt aktueller Variablen |
| Sehen, was wirklich in Cookies und localStorage steht | Aus den Request-Headern erraten | Vollständige Tabellen — Name, Wert, Domain, Ablauf, Secure, HttpOnly, SameSite — und editierbar |
| Eine H5-Seite debuggen, die in einer App steckt | Im Datenverkehr vergraben, ohne Möglichkeit sich anzuhängen | Nach zugehöriger App aufgelistet: auswählen und wie jede andere Seite debuggen |
| Remote-Debugging überhaupt zum Laufen bringen | Plattformspezifische Schalter, versteckte Einstiegspunkte, fummelige Schritte | Ein Dialog: Gerät wählen, Seite wählen, auf Debuggen klicken |
| Datenverkehr und Seitenzustand zusammen betrachten | Ein Mitschnittwerkzeug und ein Debugger, nebeneinander, ohne Bezug | Beides in einem Werkzeug: die entschlüsselte Anfrage und der Code, der sie gesendet hat |
Echte Entwicklerwerkzeuge, auf das Gerät gerichtet
Kein abgespeckter Betrachter — dieselben Panels wie am Desktop, nur an der Seite auf dem Handy.
Console: Fehler und Live-REPL
Jeder Fehler und jedes Log der Seite, dazu eine Eingabezeile, die Ihr JavaScript in genau dieser Seite auf genau diesem Gerät ausführt. Schluss mit Debuggen per alert().
Sources: Breakpoints und Einzelschritte
Durch die geladenen Skripte und Stylesheets blättern, Breakpoints setzen, den Aufrufstapel durchgehen und die Variablen genau in dem Moment ansehen, in dem es schiefgeht.
Network: jede Anfrage als Wasserfall
Status, Typ, Auslöser, Größe, Timing und Cache-Zustand pro Anfrage — dazu Summen für Anfragen, übertragene Bytes, DOMContentLoaded und die gesamte Ladezeit.
Storage: Cookies, Local und Session
Cookies nach Domain gruppiert, mit Ablauf, Secure, HttpOnly und SameSite, daneben localStorage und sessionStorage — der schnellste Weg zu einem Bug im Login-Zustand.
Der Gerätebildschirm auf Ihrem Bildschirm
Unter Android wird die laufende Seite neben den Panels gespiegelt und lässt sich mit der Maus bedienen — prüfen und bedienen auf einem Bildschirm, statt zwischen Handy und Tastatur zu wechseln.
So sieht das aus
Echte Sitzungen an einem echten Handy — nichts gestellt.
Was Sie debuggen können
Handys, Tablets, Emulatoren und Simulatoren — plus einen Browser auf dem eigenen Rechner.
| Dieser Rechner | iOS | Android | |
|---|---|---|---|
| Browser-Tabs | ✓ | ✓ | ✓ |
| Seiten in Apps (WebView / WKWebView / H5) | ✓ | ✓ | ✓ |
| Emulator / Simulator | — | ✓ | ✓ |
| Elemente und Stile live prüfen und ändern | ✓ | ✓ | ✓ |
| Konsole, Breakpoints und Einzelschritte | ✓ | ✓ | ✓ |
| Netzwerk-Wasserfall für die Seite | ✓ | ✓ | ✓ |
| Cookies / localStorage / sessionStorage | ✓ | ✓ | ✓ |
| Gerätebildschirm neben den Panels | — | — | ✓ |
| Kein Zertifikat, kein Proxy einzurichten | ✓ | ✓ | ✓ |
Einmalige Vorbereitung, bevor es losgeht
Die drei Blöcke unten sind Alternativen — machen Sie den, der zu Ihrem Ziel passt, und das nur einmal.
iOS-Gerät
Kabel anstecken und das Gerät entsperrt lassen. Für Safari: Einstellungen → Safari → Erweitert → Web-Inspector einschalten; für Chrome: Chrome-Einstellungen → Inhaltseinstellungen → Web-Inspector.
Android-Gerät
Kabel anstecken und USB-Debugging in den Entwickleroptionen aktivieren. Emulatoren werden meist auch ohne Kabel erkannt.
Browser am Rechner
Chrome oder Edge mit --remote-debugging-port=9222 starten, dann in der Seitenliste auf Aktualisieren klicken.
Auch eine Seite in einer App? Dann noch das hier
Für reine Browser-Tabs nicht nötig. Eigene App: unter Android einmal setWebContentsDebuggingEnabled(true) aufrufen, ab iOS 16.4 am WKWebView isInspectable = true setzen. Fremde App oder keine Code-Änderung: „Seiten in Apps mit einbeziehen“ anhaken — dann stehen auch die Seiten laufender Apps in der Liste. Unter Android ist Root nötig, unter iOS klappt es nur bei entwicklersignierten Apps.
Danach besteht jede Sitzung nur noch daraus
Neue Aufzeichnung → Ziel (Dieser Rechner / iOS / Android) → Methode „Web-Inspector“ → Aktualisieren → Seite wählen → Inspect. Im Browser öffnen sich vollwertige Entwicklerwerkzeuge; beliebig viele gleichzeitig.
Auch die Seiten, die in Apps stecken
Die meisten Apps sind halb nativ, halb Web. In diesen eingebetteten H5-Seiten sitzen die unangenehmen Fehler — und gewöhnliche Werkzeuge zeigen davon nichts.
Nach zugehöriger App gruppiert
Die Seitenliste ist nach App geordnet, sodass Sie eine Kassenseite in der App auf einen Blick von einem Browser-Tab unterscheiden und sich genau an die richtige hängen.
Ein Häkchen genügt
„Seiten in Apps einbeziehen“ nimmt die Seiten aus aktuell laufenden Apps mit in die Liste auf. Häkchen weg, und es bleiben wieder nur Browser-Tabs.
Es bleibt nichts zurück
Sie bauen die App nicht neu, signieren nichts und installieren keinen Helfer auf dem Gerät. Endet die Sitzung, ist das Gerät wieder wie zuvor.
Zusammen mit dem Mitschnitt
Debuggen Sie hier die Seite und schneiden Sie im selben Werkzeug den Verkehr derselben App mit — entschlüsseltes HTTPS, auch bei Apps mit Zertifikats-Pinning oder ohne Proxy-Unterstützung.
Mobiles Web-Debugging: häufige Fragen
Wie untersuche ich ein Element auf dem Handy?
Verbinden Sie das Handy per USB mit dem Rechner, öffnen Sie Trace Eagle, wählen Sie Neuer Mitschnitt → iOS oder Android → Methode „Web-Inspector“, wählen Sie die Seite und klicken Sie auf Debuggen. Auf dem Desktop öffnet sich ein vollständiges Elements-Panel mit dem lebenden DOM und CSS der Seite auf dem Gerät; ändern Sie dort einen Wert, ändert sich die Seite auf dem Handy sofort.
Kann ich eine Android-WebView debuggen, ohne die App zu ändern?
Ja. WebViews, die Debugging bereits erlauben, erscheinen direkt in der Liste. Bei Apps, die das nicht tun, kreuzen Sie „Seiten in Apps einbeziehen“ an, und die Seiten aus aktuell geöffneten Apps kommen dazu — dafür ist ein gerootetes Gerät nötig, aber es wird nichts neu gebaut, neu gepackt oder dauerhaft installiert.
Wie debugge ich eine Webseite auf einem iPhone oder iPad?
Gerät anstecken, entsperren und Einstellungen → Safari → Erweitert → Web-Inspector einschalten (oder Chrome-Einstellungen → Inhaltseinstellungen → Web-Inspector). Dann in Trace Eagle Gerät und Seite wählen und auf Debuggen klicken — der vollständige Web-Inspector öffnet sich im Desktop-Browser, mit Elements, Console, Sources, Network, Storage, Layers und mehr.
Ist das dasselbe wie chrome://inspect?
Es erledigt dieselbe Aufgabe und mehr, in einem Dialog. Die Remote-Debugging-Seite des Browsers kennt nur Chromium-Ziele unter Android; hier stehen iOS, Android und der lokale Browser in derselben Auswahl, Seiten sind nach App gruppiert, H5-Seiten in Apps kommen per Häkchen dazu — und daneben liegt ein Mitschnittwerkzeug, das den HTTPS-Verkehr derselben App entschlüsselt.
Brauche ich einen Jailbreak oder Root?
Für gewöhnliches Debuggen nicht: Browser-Tabs und Apps, die es ohnehin erlauben, funktionieren auf einem unveränderten Gerät. Nur die zusätzliche Option, Seiten aus Dritt-Apps aufzunehmen, braucht ein gerootetes Android-Gerät; unter iOS bestimmt das System, welche Apps einbezogen werden können.
Braucht es ein Zertifikat, einen Proxy oder ein SDK in der App?
Nichts davon. Das Remote-Debugging läuft über die USB-Verbindung: kein Proxy einzurichten, kein Root-Zertifikat auf dem Gerät, kein SDK und keine Bibliothek in der App.
Worin unterscheidet sich das vom Mitschneiden des Verkehrs?
Der Mitschnitt beantwortet, was über das Netz ging — Anfrage, Antwort, Header und Body, entschlüsselt. Der Web-Inspector beantwortet, was die Seite getan hat — DOM, Stile, Konsolenfehler, welches Skript die Anfrage ausgelöst hat und was vorher schon in Cookies und Storage stand. Trace Eagle bringt beides mit, sodass Sie ohne Werkzeugwechsel hin- und herspringen.
Welcher Browser öffnet das Debugging-Fenster?
Sitzungen für Android und den lokalen Browser öffnen sich in Chrome, Edge oder Brave (Trace Eagle startet einen davon für Sie); iOS-Sitzungen laufen in jedem Browser.
Funktioniert das mit Emulatoren und Simulatoren?
Ja. Android-Emulatoren werden meist ganz ohne Kabel erkannt, und auf dem Rechner laufende iOS-Simulatoren ebenfalls — der Ablauf ist identisch mit einem echten Gerät.
Ist der Web-Inspector kostenlos?
Ja. Wie alles andere in Trace Eagle ist er komplett kostenlos, unter macOS, Windows und Linux, ohne Funktionssperren.