Wenn jemand auf den Button zum Melden klickt, passiert eine ganze Menge, wovon die Person nichts sieht. Hier ist alles, und warum jedes Teil dabei ist.
Console-Logs, auch aus der Vergangenheit
Das Offensichtliche, mit einem nicht offensichtlichen Detail: BugDump erfasst Logs von vor dem Öffnen des Widgets.
Das ist wichtiger, als es klingt. Der Ablauf bei einem echten Fehlerbericht ist fast nie „Fehler tritt auf, Person meldet ihn sofort“. Sondern: Ein Fehler tritt auf, die Seite gerät in einen subtil kaputten Zustand, die Person probiert noch drei Dinge, ist verwirrt und meldet es vier Minuten später.
Ein Collector, der erst beim Melden startet, erfasst diese vier Minuten Verwirrung und verpasst den Fehler, der sie ausgelöst hat. Das SDK installiert seinen Console-Collector schon beim Init, deshalb ist der ursprüngliche Fehler noch da, wenn der Bericht schließlich abgeschickt wird.
Netzwerk-Requests
Methode, URL, Status, Timing. Hier stecken die meisten Bugs tatsächlich: nicht in deinem Frontend-Code, sondern in der Response, die dein Frontend bekommen hat.
Request- und Response-Bodys lassen sich mit captureNetworkBodies einschalten und sind standardmäßig aus. Dieser Standard ist Absicht. Nirgends tauchen Auth-Tokens, personenbezogene Daten und Zahlungsdaten so wahrscheinlich auf wie in Bodys. Sie einzuschalten sollte deine Entscheidung sein, kein Standard, den du erbst.
Auch ohne Bodys lösen Statuscodes und Timings die meisten Bugs. Ein 500, direkt bevor die Person aufgegeben hat, ist dein Bug. Ein 200, das neun Sekunden gedauert hat, ist auch dein Bug, und zwar einer, den dein Error-Tracker nie gemeldet hat.
Screenshots und das Weichzeichnen
Screenshots gibt es in zwei Varianten, und es lohnt sich, den Unterschied zu verstehen.
screen-capture nutzt getDisplayMedia. Das ist pixelgenau: Canvas, Video, Cross-Origin-iframes, native Selects, alles wird genau so erfasst, wie es gerendert ist. Der Preis ist ein Berechtigungsdialog des Browsers.
dom rendert mit html2canvas aus dem DOM. Keine Abfrage, also keine Hürde, aber Canvas-Inhalte und Cross-Origin-iframes überstehen das womöglich nicht.
Standardmäßig nutzt BugDump screen-capture und fällt automatisch auf dom zurück, wenn die Person die Berechtigung verweigert. Eine abgelehnte Abfrage soll den Screenshot verschlechtern, nicht den Bericht kosten.
Dann die Annotation: Pfeil, Rechteck, Zeichnen, Text und Weichzeichnen. Das Weichzeichnen verdient besondere Erwähnung, weil es eine Datenschutzfunktion ist, die als Zeichenwerkzeug daherkommt. Weichgezeichnet wird im Browser, ein weichgezeichneter Bereich wird nie hochgeladen. Wer sonst keinen Screenshot einer Seite mit Kundendaten schicken würde, kann jetzt einen schicken.
Session-Replay
Eine rrweb-Aufzeichnung des DOM über die Zeit. Kein Video, sondern eine Wiedergabe des echten Dokuments, das du inspizieren kannst.
Replay verdient seinen Platz bei der Art von Bug, bei der die Console sauber ist, das Netzwerk sauber ist und die Person absolut sicher ist, dass etwas kaputtgegangen ist. Meistens hat sie recht, und meistens hat sie etwas anderes getan, als sie beschreibt. Das Replay zeigt dir den Unterschied.
Interaktionen
Klicks, Eingaben und Navigation, in der richtigen Reihenfolge.
Das ist das unscheinbarste Signal und eines der nützlichsten, denn es sind deine Schritte zur Reproduktion, aufgezeichnet statt aus dem Gedächtnis. „Schritte zur Reproduktion“ ist das Feld, das am schlechtesten ausgefüllt wird, und das, das du am dringendsten brauchst. Also habe ich aufgehört zu fragen und angefangen aufzuzeichnen.
Sprachnotizen
Manche schreiben keine drei Sätze, reden aber gern zwanzig Sekunden lang. Frust transportiert außerdem Informationen, die im Text verloren gehen: Du hörst, an welcher Stelle im Ablauf es die Person wirklich erwischt hat.
Performance-Timings
Ladezeit der Seite und Resource-Timing, für die Berichte, in denen es eigentlich um Langsamkeit geht. „Die App ist langsam“ ist ein echter Fehlerbericht, und ohne Timings einer, den man weder belegen noch widerlegen kann.
Metadaten
Browser, Betriebssystem, Viewport-Größe, Seiten-URL, Zeitstempel.
Der Viewport wird am meisten unterschätzt. Ein überraschend großer Teil der Berichte nach dem Muster „der Button geht nicht“ sind Layout-Bugs bei einer Breite, die niemand getestet hat. Fast niemand denkt daran, die Fenstergröße zu erwähnen. Es ist eine einzige Zahl, sie wird automatisch erfasst, und sie erledigt eine Kategorie von Bugs, die sonst wirklich schwer zu reproduzieren ist.
Was ich bewusst weglasse
Keine Pflicht, sich zu identifizieren. Name und E-Mail liegen in einem eingeklappten Bereich. Ein Bericht ohne Namen ist trotzdem ein Bericht, und ein Formular, das eine Identität verlangt, bekommt weniger davon.
Kein Pflichtfeld für Titel, Kategorie, Schweregrad oder Priorität. Das sind Triage-Felder, die sich als Meldefelder verkleiden. Die Leute raten, raten falsch, und du sortierst ohnehin neu. Das einzige Pflichtfeld ist die Beschreibung.
Nichts sickert in deine Seite. Das Widget rendert in einem Shadow DOM. Dein CSS erreicht es nicht, und sein CSS erreicht deine Seite nicht.
Das Prinzip dahinter
Jedes Signal hier folgt einer Regel: Wenn der Browser es schon weiß, sollte die Person es nicht sagen müssen.
Die Aufgabe der Person ist ein Satz darüber, was sie erwartet hat. Alles andere ist meine Aufgabe, und das meiste davon hat der Browser schon erledigt.
Die Vorlage für Fehlerberichte, die funktioniert (und wie du sie überflüssig machst) – eine Vorlage zum Kopieren und welche ihrer Felder eine Maschine besser ausfüllt als ein Mensch.
Session-Replay ohne Überwachung – warum das Replay an einem Bericht hängt und nicht an einer Person, und was davon standardmäßig aus ist.
So erfasst du Console-Logs und Netzwerk-Requests aus fremden Browsern – wie die Capture-Schicht unter der Haube funktioniert und an welchen Fallen naive Implementierungen scheitern.