Im letzten Quartal 2019 begann das Chrome-Entwicklertools-Team damit, das Entwicklungsteam in den Entwicklertools rund um Cookies zu verbessern. Dies war besonders wichtig, da Google Chrome und andere Browser damit begonnen hatten, das Standardverhalten von Cookies zu ändern.
Bei der Recherche zu den Tools, die die Entwicklertools bereits bieten, stoßen wir oft auf folgende Situation:
😰 In der Konsole gab es zahlreiche Warnungen und Fehlermeldungen, die eher technische Erklärungen enthielten und manchmal Links zu chromestatus.com enthielten. Alle Nachrichten waren ungefähr gleich wichtig, sodass es schwierig war, herauszufinden, welches zuerst behoben werden sollte. Noch wichtiger war aber, dass der Text nicht auf zusätzliche Informationen in den Entwicklertools verweist, sodass es schwer nachvollziehbar war, was passiert ist. Und schließlich überlassen die Nachrichten oft dem Webentwickler, wie er das Problem beheben kann oder um mehr über den technischen Kontext zu erfahren.
Wenn Sie die Konsole auch für Nachrichten aus Ihrer eigenen Anwendung verwenden, haben Sie manchmal Schwierigkeiten, sie zwischen den Nachrichten aus dem Browser zu finden.
Ebenso wie für Menschen ist es auch für automatisierte Prozesse schwierig, mit Nachrichten der Konsole zu interagieren. Entwickler können beispielsweise Chrome Headless und Puppeteer in einem Szenario für Continuous Integration/Continuous Deployment verwenden. Da Konsolennachrichten nur Strings sind, müssen Entwickler reguläre Ausdrücke oder einen anderen Parser schreiben, um verwertbare Informationen zu extrahieren.
Die Lösung: strukturierte und handlungsrelevante Problemberichte
Um eine bessere Lösung für die von uns entdeckten Probleme zu finden, haben wir zuerst über die Anforderungen nachgedacht und sie in einem Designdokument zusammengefasst.
Unser Ziel ist es, Probleme so darzustellen, dass das Problem klar erklärt wird und wie es behebt wird. Aus unserem Designprozess haben wir erkannt, dass jedes Problem die folgenden vier Teile umfassen sollte:
- Titel
- Beschreibung
- Links zu betroffenen Ressourcen in den Entwicklertools
- Link zu weiteren Informationen
Der Titel sollte kurz und präzise sein, damit Entwickler das Kernproblem besser nachvollziehen können. Häufig ist schon ein Hinweis zur Problembehebung vorhanden. Ein Cookie-Problem könnte jetzt beispielsweise so lauten:
Websiteübergreifende Cookies als sicher markieren, damit sie in websiteübergreifenden Kontexten gesetzt werden können
Jedes Problem enthält ausführlichere Informationen in einer Beschreibung, die erklärt, was passiert ist, gibt praktische Ratschläge zur Behebung des Problems und Links zu anderen Bereichen in den Entwicklertools, um das Problem im Kontext zu verstehen. Auf web.dev finden Sie Links zu ausführlichen Artikeln, mit denen Webentwickler mehr über das Thema erfahren können.
Ein wichtiger Teil jedes Problems ist der Abschnitt Betroffene Ressourcen, der auf andere Bereiche der Entwicklertools verweist und eine weitere Untersuchung erleichtert. Im Beispiel für das Cookie-Problem sollte eine Liste der Netzwerkanfragen enthalten sein, die das Problem ausgelöst haben. Wenn Sie auf die Anfrage klicken, werden Sie direkt zum Bereich „Network“ (Netzwerk) weitergeleitet. Wir hoffen, dass dies nicht nur praktisch ist, sondern auch, welche Bereiche und Tools in den Entwicklertools verwendet werden können, um eine bestimmte Art von Problem zu beheben.
Wenn wir die langfristige Interaktion von Entwicklern mit dem Tab „Probleme“ langfristig betrachten, stellen wir uns die folgende Entwicklung der Interaktion zwischen Entwicklern vor:
- Wenn ein bestimmtes Problem zum ersten Mal auftrat, liest ein Webentwickler den Artikel, um sich ausführlich mit dem Problem vertraut zu machen.
- Wenn das Problem zum zweiten Mal auftritt, hoffen wir, dass die Problembeschreibung ausreicht, um den Entwickler an das Problem zu erinnern und ihm die Möglichkeit zu geben, das Problem sofort zu untersuchen und entsprechende Maßnahmen zur Lösung zu ergreifen.
- Nachdem ein Problem einige Male aufgetreten ist, hoffen wir, dass der Titel des Problems ausreicht, damit der Entwickler die Art des Problems erkennen kann.
Ein weiterer wichtiger Aspekt, den wir verbessern wollten, ist die Aggregation. Wenn beispielsweise dasselbe Cookie mehrmals dasselbe Problem verursacht hat, soll es nur einmal gemeldet werden. Dies hilft nicht nur, die Anzahl der Nachrichten deutlich zu reduzieren, sondern hilft häufig auch, die Ursache eines Problems schneller zu identifizieren.
Die Implementierung
Unter Berücksichtigung dieser Anforderungen begann das Team mit der Implementierung der neuen Funktion. Projekte für die Chrome-Entwicklertools umfassen in der Regel drei verschiedene Bereiche:
- Chromium, das in C++ geschriebene Open-Source-Projekt hinter Google Chrome
- DevTools-Frontend, die JavaScript-Implementierung der Chrome-Entwicklertools
- Das Chrome DevTools Protocol (CDP), die Schicht zwischen den beiden Tools
Die Implementierung umfasste dann drei Aufgaben:
- In Chromium mussten wir die Komponenten identifizieren, die die gewünschten Informationen enthalten, und diese für das Entwicklertools-Protokoll zugänglich machen, ohne die Geschwindigkeit oder Sicherheit zu beeinträchtigen.
- Anschließend mussten wir das Chrome DevTools Protocol (CDP) entwerfen, um die API zu definieren, die die Informationen für Clients wie das DevTools-Front-End bereitstellt.
- Schließlich musste eine Komponente im DevTools-Frontend implementiert werden, die die Informationen über CDP vom Browser anfordert und in einer entsprechenden Benutzeroberfläche anzeigt, sodass Entwickler die Informationen einfach interpretieren und damit interagieren können.
Für den Browser haben wir uns zuerst angesehen, wie Konsolennachrichten gehandhabt werden, da ihr Verhalten dem bei Problemen entspricht. CodeSearch ist normalerweise ein guter Ausgangspunkt für explorative Datenanalysen wie diese. Damit können Sie den gesamten Quellcode des Chromium-Projekts online durchsuchen und untersuchen. Auf diese Weise haben wir mehr über die Implementierung von Konsolennachrichten erfahren und konnten eine parallele, aber strukturiertere Methode für die Anforderungen entwickeln, die wir für die Probleme gesammelt haben.
Diese Arbeit ist angesichts der vielen Sicherheitsaspekte, die wir immer im Hinterkopf behalten müssen, besonders schwierig. Im Chromium-Projekt werden Dinge viel auf unterschiedliche Prozesse aufgeteilt und nur über kontrollierte Kommunikationskanäle kommuniziert, um Datenlecks zu verhindern. Da Probleme vertrauliche Daten enthalten können, müssen wir darauf achten, dass diese Informationen nicht an ungewünschte Bereiche des Browsers gesendet werden.
Im Frontend der Entwicklertools
Die DevTools selbst sind eine in JavaScript und CSS geschriebene Webanwendung. Sie ähneln vielen anderen Webanwendungen, nur dass sie bereits seit über 10 Jahren verfügbar sind. Und natürlich ist das Backend im Grunde ein direkter Kommunikationskanal zum Browser: das Chrome DevTools Protocol.
Beim Tab „Probleme“ haben wir uns zuerst über User Storys und darüber nachgedacht, wie Entwickler ein Problem beheben müssen. Unser Ziel war es, den Tab „Probleme“ als zentralen Ausgangspunkt für Untersuchungen zu nutzen, bei denen Nutzer zu Bereichen mit detaillierteren Informationen verlinkt wurden. Wir haben uns entschieden, den Tab „Probleme“ zusammen mit den anderen Tabs unten in den Entwicklertools zu platzieren, damit er geöffnet bleibt, während ein Entwickler mit einer anderen Entwicklertools-Komponente interagiert, z. B. dem Bereich „Netzwerk“ oder „Anwendung“.
Vor diesem Hintergrund haben unsere UX-Designschaffenden verstanden, was wir erreichen wollten, und einen Prototyp für die folgenden ersten Vorschläge erstellt:
Nach regen Diskussion über die beste Lösung haben wir mit der Implementierung des Designs und der Wiederholung der Entscheidungen begonnen, um nach und nach zu dem Tab „Probleme“ von heute zu gelangen.
Ein weiterer sehr wichtiger Faktor war die Sichtbarkeit des Tabs „Probleme“. Früher waren viele der Funktionen der Entwicklertools nur dann zu finden, wenn die Entwickler genau wussten, worauf sie achten sollten. Auf dem Tab „Probleme“ haben wir beschlossen, Probleme in mehreren verschiedenen Bereichen hervorzuheben, damit Entwickler keine wichtigen Probleme verpassen.
Wir haben beschlossen, eine Benachrichtigung im Konsolenbereich hinzuzufügen, da bestimmte Nachrichten aus der Konsole jetzt zugunsten von Problemen entfernt werden. Außerdem haben wir dem Zähler für Warnungen und Fehler oben rechts im Fenster „Entwicklertools“ ein Symbol hinzugefügt.
Auf dem Tab „Probleme“ findest du nicht nur Links zu anderen Entwicklertools, sondern auch Ressourcen zu einem Problem.
Im Protokoll
Die Kommunikation zwischen dem Frontend und dem Backend erfolgt über ein Protokoll namens Chromium DevTools Protocol (CDP). Die CDP kann man sich als Back-End der Webanwendung vorstellen, die die Chrome-Entwicklertools sind. Die CDP ist in mehrere Domains unterteilt und jede Domain enthält eine Reihe von Befehlen und Ereignissen.
Wir haben auf dem Tab „Probleme“ beschlossen, der Audits-Domain ein neues Ereignis hinzuzufügen, das jedes Mal ausgelöst wird, wenn ein neues Problem auftritt. Damit wir auch Probleme melden können, die auftreten, wenn die Entwicklertools noch nicht geöffnet sind, speichert die Audits-Domain die neuesten Probleme und leitet sie weiter, sobald die Entwicklertools eine Verbindung hergestellt haben. Die Entwicklertools sammeln dann alle diese Probleme und fassen sie zusammen.
Das CDP ermöglicht auch anderen Protokollclients, wie z. B. Puppeteer, Probleme zu empfangen und zu verarbeiten. Wir hoffen, dass die über die CDP gesendeten strukturierten Probleminformationen die Integration in die bestehende Continuous-Integration-Infrastruktur ermöglichen und vereinfachen. So können Probleme bereits vor der Bereitstellung der Seite erkannt und behoben werden.
Zukünftig
Erstens müssen wesentlich mehr Meldungen von der Konsole auf den Tab „Probleme“ verschoben werden. Dies wird einige Zeit dauern, vor allem, weil wir für jedes neu hinzugefügte Problem klare, umsetzbare Dokumentationen zur Verfügung stellen möchten. Wir hoffen, dass Entwickler in Zukunft statt in der Konsole auf dem Tab „Probleme“ nach Problemen suchen werden.
Außerdem überlegen wir, wie wir Probleme aus anderen Quellen als dem Chromium-Back-End auf dem Tab „Probleme“ integrieren können.
Wir arbeiten daran, den Tab „Probleme“ übersichtlicher zu gestalten und die Nutzerfreundlichkeit zu verbessern. Suchen, Filtern und eine bessere Aggregation stehen dieses Jahr auf unserer Liste. Um die zunehmende Anzahl gemeldeter Probleme zu strukturieren, führen wir derzeit Problemkategorien ein, mit denen beispielsweise nur Probleme mit bevorstehenden Einstellungen angezeigt werden können. Wir denken auch über eine Schlummerfunktion nach, mit der Entwickler Probleme vorübergehend ausblenden können.
Damit Probleme bereinigt und nutzbar sind, möchten wir es einfacher machen, zu erkennen, welcher Teil einer Seite ein Problem verursacht hat. Wir suchen insbesondere nach Möglichkeiten, um Probleme zu unterscheiden und herauszufiltern, die tatsächlich von Ihrer Seite (d. h. selbst erhobene) stammen, von Problemen, die durch eingebettete Ressourcen ausgelöst werden, die aber nicht direkt von Ihnen kontrolliert werden (z. B. ein Werbenetzwerk). Zuerst wird es möglich sein, Probleme mit Drittanbieter-Cookies in Chrome 86 auszublenden.
Wenn du Vorschläge zur Verbesserung des Tabs „Probleme“ hast, kannst du uns einen Fehler melden.
Vorschaukanäle herunterladen
Sie können Chrome Canary, Dev oder Beta als Standardbrowser für die Entwicklung verwenden. Über diese Vorschaukanäle erhältst du Zugriff auf die neuesten Entwicklertools-Funktionen, kannst neue Webplattform-APIs testen und Probleme auf deiner Website erkennen, bevor deine Nutzer es tun.
Chrome-Entwicklertools-Team kontaktieren
Verwende die folgenden Optionen, um die neuen Funktionen und Änderungen im Beitrag oder andere Themen im Zusammenhang mit den Entwicklertools zu besprechen.
- Sende uns über crbug.com Vorschläge oder Feedback.
- Wenn du ein Problem mit den Entwicklertools melden möchtest, klicke in den Entwicklertools auf Weitere Optionen
> Hilfe > Probleme mit den Entwicklertools melden. - Senden Sie einen Tweet an @ChromeDevTools.
- Hinterlasse Kommentare zu den Neuheiten in den Entwicklertools YouTube-Videos oder YouTube-Videos in den Entwicklertools-Tipps.