Im letzten Quartal 2019 hat das Chrome-Entwicklertools-Team damit begonnen, die Nutzerfreundlichkeit der Chrome-Entwicklertools im Hinblick auf Cookies zu verbessern. Das war besonders wichtig, da Google Chrome und andere Browser damit begonnen hatten, ihr Standard-Cookie-Verhalten zu ändern.
Bei der Recherche zu den bereits vorhandenen Tools in den DevTools haben wir uns oft in einer Situation wiedergefunden, die so aussah:
😰 Die Konsole war voller Warnungen und Fehlermeldungen, die eher technische Erklärungen und manchmal Links zu chromestatus.com enthielten. Alle Nachrichten schienen ungefähr gleich wichtig zu sein, sodass es schwierig war, herauszufinden, welche zuerst zu beheben war. Noch wichtiger ist, dass der Text nicht auf zusätzliche Informationen in DevTools verlinkte, was es schwierig machte, zu verstehen, was passiert ist. Und schließlich war es oft dem Webentwickler überlassen, herauszufinden, wie das Problem behoben werden kann oder sich über den technischen Kontext zu informieren.
Wenn Sie die Konsole auch für Nachrichten aus Ihrer eigenen Anwendung verwenden, kann es manchmal schwierig sein, sie zwischen den Nachrichten des Browsers zu finden.
Nicht nur für Menschen, sondern auch für automatisierte Prozesse ist es schwierig, mit Konsolennachrichten zu interagieren. Entwickler könnten beispielsweise Chrome Headless und Puppeteer in einem Szenario mit Continuous Integration/Continuous Deployment verwenden. Da Konsolenmeldungen nur Strings sind, müssen Entwickler reguläre Ausdrücke oder einen anderen Parser schreiben, um umsetzbare Informationen zu extrahieren.
Die Lösung: strukturierte und umsetzbare Problemberichte
Um eine bessere Lösung für die erkannten Probleme zu finden, haben wir uns zuerst Gedanken über die Anforderungen gemacht und sie in einem Designdokument zusammengestellt.
Unser Ziel ist es, Probleme so zu präsentieren, dass sie klar erklärt werden und wie sie behoben werden. Bei unserem Designprozess haben wir festgestellt, dass jedes Problem die folgenden vier Teile enthalten sollte:
- Titel
- Beschreibung
- Links zu betroffenen Ressourcen in DevTools
- und einen Link zu weiteren Informationen
Der Titel sollte kurz und präzise sein, damit Entwickler das Kernproblem verstehen können. Oft enthält er bereits Hinweise auf die Lösung. Ein Cookie-Problem wird jetzt beispielsweise so angezeigt:
Websiteübergreifende Cookies als „Sicher“ kennzeichnen, um sie in websiteübergreifenden Kontexten festzulegen
Jedes Problem enthält eine Beschreibung mit detaillierteren Informationen, in der erklärt wird, was passiert ist, praktische Tipps zur Fehlerbehebung gegeben werden und Links zu anderen Bereichen in den DevTools enthalten sind, um das Problem im Kontext zu verstehen. Außerdem finden Webentwickler auf web.dev Links zu ausführlichen Artikeln, in denen sie sich über das Thema informieren können.
Ein wichtiger Teil jedes Problems ist der Abschnitt Betroffene Ressourcen. Er enthält Links zu anderen Teilen von DevTools und erleichtert die weitere Untersuchung. Im Beispiel für das Cookie-Problem sollte eine Liste der Netzwerkanfragen angezeigt werden, die das Problem ausgelöst haben. Wenn Sie auf die Anfrage klicken, gelangen Sie direkt zum Bereich „Netzwerk“. Wir hoffen, dass dies nicht nur praktisch ist, sondern auch verdeutlicht, welche Bereiche und Tools in den DevTools zur Behebung bestimmter Probleme verwendet werden können.
Wir stellen uns die Interaktion von Entwicklern mit dem Tab „Probleme“ langfristig so vor:
- Wenn ein Webentwickler zum ersten Mal auf ein bestimmtes Problem stößt, würde er den Artikel lesen, um das Problem genau zu verstehen.
- Wenn das Problem zum zweiten Mal auftritt, sollte die Problembeschreibung ausreichen, um den Entwickler daran zu erinnern, worum es ging, und ihm die Möglichkeit zu geben, es sofort zu untersuchen und Maßnahmen zur Behebung zu ergreifen.
- Wenn ein Problem mehrmals auftritt, sollte der Titel ausreichen, damit Entwickler die Art des Problems erkennen können.
Ein weiterer wichtiger Aspekt, den wir verbessern möchten, ist die Aggregation. Wenn beispielsweise dasselbe Cookie mehrmals dasselbe Problem verursacht hat, wollten wir das Cookie nur einmal melden. Dadurch lässt sich nicht nur die Anzahl der Meldungen erheblich reduzieren, sondern oft auch die Ursache eines Problems schneller ermitteln.
Implementierung
In Anbetracht dieser Anforderungen begann das Team, sich Gedanken darüber zu machen, wie die neue Funktion implementiert werden könnte. Projekte für die Chrome-Entwicklertools umfassen in der Regel drei verschiedene Bereiche:
- Chromium, das in C++ geschriebene Open-Source-Projekt, das Google Chrome zugrunde liegt
- DevTools-Frontend, die JavaScript-Implementierung der Chrome-Entwicklertools
- Chrome DevTools Protocol (CDP), die Schicht, die beide verbindet
Die Implementierung umfasste dann drei Aufgaben:
- In Chromium mussten wir die Komponenten mit den gewünschten Informationen ermitteln und diese Informationen für das DevTools-Protokoll zugänglich machen, ohne Geschwindigkeit oder Sicherheit zu beeinträchtigen.
- Anschließend mussten wir das Chrome DevTools Protocol (CDP) entwerfen, um die API zu definieren, über die die Informationen für Clients wie die DevTools-Frontend freigegeben werden.
- Schließlich mussten wir eine Komponente in der DevTools-Frontend-Ansicht implementieren, die die Informationen über die CDP vom Browser anfordert und in einer geeigneten Benutzeroberfläche anzeigt, damit Entwickler die Informationen leicht interpretieren und damit interagieren können.
Auf der Browserseite haben wir uns zuerst angesehen, wie Konsolennachrichten verarbeitet wurden, da ihr Verhalten sehr ähnlich ist wie das, was wir uns für Probleme vorgestellt hatten. CodeSearch ist in der Regel ein guter Ausgangspunkt für solche explorativen Datenanalysen. Sie können damit den gesamten Quellcode des Chromium-Projekts online durchsuchen. So haben wir mehr über die Implementierung von Konsolennachrichten erfahren und konnten parallel, aber strukturierter an den Anforderungen arbeiten, die wir für die Probleme gesammelt hatten.
Die Arbeit hier ist besonders anspruchsvoll, da wir immer die Sicherheitsaspekte im Auge behalten müssen. Das Chromium-Projekt bietet viele Möglichkeiten, Elemente in verschiedene Prozesse aufzuteilen und diese nur über kontrollierte Kommunikationskanäle zu kommunizieren, um Datenlecks zu vermeiden. Probleme können vertrauliche Informationen enthalten. Daher müssen wir darauf achten, dass diese Informationen nicht an einen Teil des Browsers gesendet werden, der nicht darüber informiert sein sollte.
Im DevTools-Frontend
Die DevTools sind selbst eine Webanwendung, die in JavaScript und CSS geschrieben wurde. Sie ähnelt vielen anderen Webanwendungen, mit der Ausnahme, dass sie seit mehr als 10 Jahren existiert. Und natürlich ist das Backend im Grunde ein direkter Kommunikationskanal zum Browser: das Chrome DevTools Protocol.
Für den Tab „Probleme“ haben wir uns zuerst Gedanken über User Storys gemacht und darüber, was Entwickler tun müssen, um ein Problem zu lösen. Unsere Ideen drehten sich hauptsächlich um den Tab „Probleme“ als zentralen Ausgangspunkt für Untersuchungen, über den Nutzer zu den Bereichen mit detaillierteren Informationen weitergeleitet wurden. Wir haben den Tab „Probleme“ zusammen mit den anderen Tabs unten in den DevTools platziert, damit er geöffnet bleiben kann, während ein Entwickler mit einer anderen DevTools-Komponente interagiert, z. B. mit dem Netzwerk- oder dem Anwendungsbereich.
Unser UX-Designer hat verstanden, was wir erreichen wollten, und die folgenden ersten Vorschläge als Prototypen erstellt:
Nach vielen Diskussionen über die beste Lösung haben wir mit der Implementierung des Designs begonnen und Entscheidungen wiederholt, um nach und nach zu dem Tab „Probleme“ zu gelangen, wie er heute aussieht.
Ein weiterer wichtiger Faktor war die Sichtbarkeit des Tabs „Probleme“. In der Vergangenheit waren viele großartige Devtools-Funktionen nicht zu finden, ohne dass der Entwickler genau wusste, wonach er suchen musste. Auf dem Tab „Probleme“ haben wir beschlossen, Probleme in verschiedenen Bereichen hervorzuheben, damit Entwickler keine wichtigen Probleme übersehen.
Wir haben uns entschieden, dem Konsolenbereich eine Benachrichtigung hinzuzufügen, da bestimmte Konsolenmeldungen jetzt zugunsten von Problemen entfernt werden. Außerdem haben wir dem Zähler für Warnungen und Fehler oben rechts im DevTools-Fenster ein Symbol hinzugefügt.
Der Tab „Probleme“ enthält nicht nur Links zu anderen DevTools-Bereichen, sondern auch zu Ressourcen, die sich auf ein Problem beziehen.
Im Protokoll
Die Kommunikation zwischen Frontend und Backend erfolgt über das Chromium DevTools Protocol (CDP). Die CDP kann als Back-End der Webanwendung angesehen werden, also als Chrome DevTools. Die CDP ist in mehrere Domains unterteilt und jede Domain enthält eine Reihe von Befehlen und Ereignissen.
Für den Tab „Probleme“ haben wir der Domain „Audits“ ein neues Ereignis hinzugefügt, das ausgelöst wird, wenn ein neues Problem auftritt. Damit wir auch Probleme melden können, die auftreten, während DevTools noch nicht geöffnet ist, werden die neuesten Probleme in der Domain „audits“ gespeichert und versendet, sobald DevTools eine Verbindung herstellt. In DevTools werden dann alle diese Probleme erfasst und zusammengefasst.
Das CDP ermöglicht auch anderen Protokollclients wie Puppeteer, Probleme zu empfangen und zu verarbeiten. Wir hoffen, dass die strukturierten Probleminformationen, die über das CDP gesendet werden, die Integration in die bestehende Continuous Integration-Infrastruktur ermöglichen und vereinfachen. So können Probleme noch vor der Bereitstellung der Seite erkannt und behoben werden.
Demnächst
Zuerst müssen noch viel mehr Meldungen aus der Konsole auf den Tab „Probleme“ verschoben werden. Das wird einige Zeit dauern, vor allem, weil wir für jede neu hinzugefügte Ausgabe klare, umsetzbare Dokumentationen bereitstellen möchten. Wir hoffen, dass Entwickler in Zukunft auf dem Tab „Probleme“ nach Problemen suchen, anstatt in der Console.
Außerdem überlegen wir, wie wir Probleme aus anderen Quellen als dem Chromium-Back-End in den Tab „Probleme“ einbinden können.
Wir arbeiten daran, den Tab „Probleme“ übersichtlich zu gestalten und die Nutzerfreundlichkeit zu verbessern. Auf unserer Liste für dieses Jahr stehen die Themen Suche, Filterung und bessere Aggregation. Um die steigende Anzahl der gemeldeten Probleme zu strukturieren, führen wir derzeit Problemkategorien ein. So können beispielsweise nur Probleme angezeigt werden, die sich auf bevorstehende Einstellungen beziehen. Wir denken auch über eine Funktion zum Zurückstellen nach, mit der Entwickler Probleme vorübergehend ausblenden können.
Damit Probleme behoben werden können, möchten wir es einfacher machen, herauszufinden, welcher Teil einer Seite ein Problem verursacht hat. Wir überlegen insbesondere, wie wir Probleme, die tatsächlich von Ihrer Seite stammen (d. h. Erstanbieterprobleme), von Problemen unterscheiden, die durch von Ihnen eingebettete Ressourcen verursacht werden, aber nicht direkt unter Ihrer Kontrolle stehen (z. B. ein Werbenetzwerk). In Chrome 86 können Sie Probleme mit Drittanbieter-Cookies in einem ersten Schritt ausblenden.
Wenn du Verbesserungsvorschläge für den Tab „Probleme“ hast, kannst du uns einen Fehler melden.
Vorschaukanäle herunterladen
Verwenden Sie als Standard-Entwicklungsbrowser Chrome Canary, Chrome Dev oder Chrome Beta. Diese Vorabversionen bieten Zugriff auf die neuesten DevTools-Funktionen, ermöglichen den Test moderner Webplattform-APIs und helfen Ihnen, Probleme auf Ihrer Website zu finden, bevor Ihre Nutzer sie bemerken.
Chrome-Entwicklertools-Team kontaktieren
Mit den folgenden Optionen können Sie über neue Funktionen, Updates oder andere Themen im Zusammenhang mit den DevTools sprechen.
- Senden Sie uns Feedback und Funktionsanfragen unter crbug.com.
- Wenn du ein Problem mit den Entwicklertools melden möchtest, klicke in den Entwicklertools auf Weitere Optionen > Hilfe > Entwicklertools-Problem melden.
- Tweeten Sie an @ChromeDevTools.
- Hinterlassen Sie Kommentare unter den YouTube-Videos zu den Neuigkeiten in den DevTools oder den YouTube-Videos mit Tipps zu den DevTools.