Hoe we het tabblad Problemen met Chrome DevTools hebben gebouwd

Jan Scheffler
Jan Scheffler
Sigurd Schneider
Sigurd Schneider
X

In het laatste kwartaal van 2019 is het Chrome DevTools-team begonnen met het verbeteren van de ontwikkelaarservaring in DevTools rond cookies. Dit was vooral belangrijk omdat Google Chrome en andere browsers hun standaard cookiegedrag begonnen te veranderen.

Tijdens het onderzoeken van de tools die DevTools al biedt, kwamen we vaak in een situatie als de volgende terecht:

Problemen in het consolepaneel

😰 De console stond vol met waarschuwingen en foutmeldingen, die nogal technische uitleg bevatten en soms links naar chromestatus.com . Alle berichten leken ongeveer even belangrijk, waardoor het moeilijk was om erachter te komen welke als eerste moesten worden behandeld . Belangrijker nog was dat de tekst geen link bevatte naar aanvullende informatie binnen DevTools, waardoor het moeilijk te begrijpen was wat er gebeurde . En ten slotte lieten de berichten het vaak volledig aan de webontwikkelaar over om uit te zoeken hoe het probleem kon worden opgelost of zelfs om meer te weten te komen over de technische context.

Als je de console ook gebruikt voor berichten uit je eigen applicatie, kun je deze soms moeilijk terugvinden tussen alle berichten uit de browser.

Net als voor mensen is het ook moeilijk voor geautomatiseerde processen om te communiceren met consoleberichten. Ontwikkelaars kunnen Chrome Headless en Puppeteer bijvoorbeeld gebruiken in een scenario voor continue integratie/continue implementatie. Omdat consoleberichten slechts tekenreeksen zijn, moeten ontwikkelaars reguliere expressies of een andere parser schrijven om bruikbare informatie te extraheren.

De oplossing: gestructureerde en bruikbare probleemrapportage

Om een ​​betere oplossing te vinden voor de problemen die we ontdekten, zijn we eerst gaan nadenken over de eisen en deze verzameld in een Design Doc .

Ons doel is om problemen op een manier te presenteren waarin het probleem duidelijk wordt uitgelegd en hoe het probleem kan worden opgelost . Vanuit ons ontwerpproces realiseerden we ons dat elk nummer de volgende vier delen moest bevatten:

  • Titel
  • Beschrijving
  • Links naar getroffen bronnen binnen DevTools
  • En een link naar verdere begeleiding

We willen dat de titel kort en nauwkeurig is om ontwikkelaars te helpen het kernprobleem te begrijpen, en vaak al naar de oplossing verwijst. Een cookieprobleem luidt nu bijvoorbeeld eenvoudigweg:

Markeer cross-site cookies als veilig, zodat u ze in een cross-site context kunt plaatsen

Elk probleem bevat meer gedetailleerde informatie in een beschrijving, waarin wordt uitgelegd wat er is gebeurd , actiegericht advies wordt gegeven over hoe het probleem kan worden opgelost, en links naar andere panelen binnen DevTools om het probleem in de context te begrijpen. We bieden ook links naar diepgaande artikelen op web.dev, zodat webontwikkelaars meer informatie over het onderwerp kunnen krijgen.

Een belangrijk onderdeel van elk probleem is de sectie met getroffen bronnen , die linkt naar andere delen van DevTools en het gemakkelijk maakt om verder te onderzoeken. Voor het voorbeeld van een cookieprobleem zou er een lijst met netwerkverzoeken moeten zijn die het probleem hebben veroorzaakt. Als u op het verzoek klikt, gaat u rechtstreeks naar het netwerkpaneel. We hopen dat dit niet alleen handig is, maar ook versterkt welke panelen en tools binnen DevTools kunnen worden gebruikt om een ​​bepaald soort probleem op te lossen.

Als we op de lange termijn nadenken over ontwikkelaarsinteractie met het tabblad Problemen, stellen we ons de volgende evolutie van ontwikkelaarsinteractie voor:

  • Wanneer een webontwikkelaar voor het eerst een bepaald probleem tegenkomt, leest hij het artikel om het probleem diepgaander te begrijpen.
  • Wanneer we het probleem voor de tweede keer tegenkomen, hopen we dat de beschrijving van het probleem voldoende is om de ontwikkelaar eraan te herinneren waar het probleem over ging, zodat hij of zij onmiddellijk onderzoek kan doen en actie kan ondernemen om het probleem op te lossen.
  • Nadat we een paar keer een probleem zijn tegengekomen, hopen we dat de titel van het probleem voldoende is voor een ontwikkelaar om het type probleem te herkennen.

Een ander belangrijk aspect dat we wilden verbeteren is aggregatie . Als dezelfde cookie bijvoorbeeld meerdere keren hetzelfde probleem veroorzaakte, wilden we de cookie slechts één keer melden. Naast dat het aantal berichten aanzienlijk wordt verminderd, helpt dit vaak ook om de hoofdoorzaak van een probleem sneller te identificeren.

Geaggregeerde problemen

De implementatie

Met deze vereisten in gedachten begon het team te onderzoeken hoe de nieuwe functie kon worden geïmplementeerd. Projecten voor Chrome DevTools omvatten doorgaans drie verschillende gebieden:

De implementatie bestond toen uit drie taken:

  • Binnen Chromium moesten we de componenten identificeren die de informatie bevatten die we naar boven wilden halen en die informatie toegankelijk maken voor het DevTools Protocol zonder de snelheid of veiligheid in gevaar te brengen.
  • Vervolgens moesten we het Chrome DevTools Protocol (CDP) ontwerpen om de API te definiëren die de informatie beschikbaar stelt aan clients, zoals de DevTools frontend.
  • Ten slotte moesten we een component in de frontend van DevTools implementeren die via CDP de informatie van de browser opvraagt ​​en deze in een geschikte gebruikersinterface weergeeft, zodat ontwikkelaars de informatie gemakkelijk kunnen interpreteren en ermee kunnen communiceren.

Wat de browserkant betreft, hebben we eerst gekeken naar hoe consoleberichten werden afgehandeld, omdat hun gedrag sterk lijkt op wat we in gedachten hadden voor problemen. CodeSearch is meestal een goed startpunt voor dit soort verkenningen. Hiermee kunt u de volledige broncode van het Chromium-project online doorzoeken en verkennen. Op die manier leerden we over de implementatie van consoleberichten en konden we een parallelle, maar meer gestructureerde manier opbouwen rond de vereisten die we voor de problemen hadden verzameld.

Het werk hier is bijzonder uitdagend vanwege alle veiligheidsimplicaties waarmee we altijd rekening moeten houden. Het Chromium-project gaat ver om dingen in verschillende processen op te delen en ze alleen via gecontroleerde communicatiekanalen te laten communiceren om informatielekken te voorkomen. Problemen kunnen gevoelige informatie bevatten, dus we moeten ervoor zorgen dat die informatie niet naar een deel van de browser wordt verzonden dat er niets van zou moeten weten.

In de DevTools-frontend

DevTools zelf is een webapplicatie geschreven in JavaScript en CSS. Het lijkt veel op veel andere webapplicaties, behalve dat het al meer dan 10 jaar bestaat. En natuurlijk is de back-end in feite een direct communicatiekanaal met de browser: het Chrome DevTools Protocol.

Voor het tabblad Problemen hebben we eerst nagedacht over gebruikersverhalen en wat ontwikkelaars zouden moeten doen om een ​​probleem op te lossen. Onze ideeën kwamen vooral voort uit het hebben van het tabblad Problemen als centraal startpunt voor onderzoeken waarbij mensen werden gekoppeld aan de panels die meer gedetailleerde informatie tonen. We hebben besloten om het tabblad Problemen samen met de andere tabbladen onderaan DevTools te plaatsen, zodat het open kan blijven terwijl een ontwikkelaar interactie heeft met een ander DevTools-onderdeel, zoals het netwerk of het toepassingspaneel.

Met dat in gedachten begreep onze UX-ontwerper waar we naar streefden en maakte een prototype van de volgende initiële voorstellen:

prototypen

Na veel discussie over de beste oplossing zijn we begonnen met het implementeren van het ontwerp en het herhalen van beslissingen om geleidelijk te komen tot hoe het tabblad Problemen er vandaag de dag uitziet.

Een andere zeer belangrijke factor was de vindbaarheid van het tabblad Problemen. In het verleden waren veel geweldige Devtools-functies niet te ontdekken zonder dat de ontwikkelaar wist waar hij specifiek op moest letten. Voor het tabblad Problemen hebben we besloten problemen op meerdere verschillende gebieden onder de aandacht te brengen, zodat ontwikkelaars geen belangrijke problemen zouden missen.

We hebben besloten een melding toe te voegen aan het consolepaneel, omdat bepaalde consoleberichten nu zijn verwijderd ten gunste van problemen. We hebben ook een pictogram toegevoegd aan de teller voor waarschuwingen en fouten in de rechterbovenhoek van het DevTools-venster.

Melding van problemen

Ten slotte linkt het tabblad Problemen niet alleen naar andere DevTools-panelen, maar verwijzen bronnen die verband houden met een probleem ook terug naar het tabblad Problemen.

Gerelateerde problemen

In het protocol

De communicatie tussen de frontend en de backend werkt via een protocol genaamd Chromium DevTools Protocol (CDP). Het CDP kan worden gezien als de back-end van de webapp Chrome DevTools. Het CDP is onderverdeeld in meerdere domeinen en elk domein bevat een aantal commando's en gebeurtenissen.

Voor het tabblad Problemen hebben we besloten een nieuwe gebeurtenis toe te voegen aan het domein Audits, die wordt geactiveerd wanneer er een nieuw probleem wordt aangetroffen. Om ervoor te zorgen dat we ook kunnen rapporteren over problemen die zich voordoen terwijl DevTools nog niet is geopend, slaat het Audits-domein de meest recente problemen op en verzendt deze zodra DevTools verbinding maakt. DevTools verzamelt vervolgens al deze problemen en voegt ze samen.

Met het CDP kunnen ook andere protocolclients, zoals Puppeteer , problemen ontvangen en verwerken. We hopen dat de gestructureerde probleeminformatie die via het CDP wordt verzonden de integratie in de bestaande infrastructuur voor continue integratie mogelijk zal maken en vereenvoudigen. Op deze manier kunnen problemen worden gedetecteerd en opgelost, zelfs voordat de pagina wordt geïmplementeerd!

Toekomst

Allereerst moeten er veel meer berichten van de console naar het tabblad Problemen worden verplaatst. Dit zal enige tijd duren, vooral omdat we duidelijke, bruikbare documentatie willen bieden voor elk nieuw probleem dat we toevoegen. We hopen dat ontwikkelaars in de toekomst naar problemen zullen zoeken op het tabblad Problemen in plaats van op de console!

Verder denken we na over hoe we problemen uit andere bronnen dan de Chromium-backend kunnen integreren in het tabblad Problemen.

We onderzoeken manieren om het tabblad Problemen overzichtelijk te houden en de bruikbaarheid te verbeteren. Zoeken, filteren en betere aggregatie staan ​​dit jaar op onze lijst. Om het toenemende aantal gerapporteerde problemen te structureren, zijn we bezig met het introduceren van probleemcategorieën die het bijvoorbeeld mogelijk maken om alleen problemen weer te geven die betrekking hebben op aanstaande beëindigingen. We denken er ook aan om een ​​snooze-functie toe te voegen, die een ontwikkelaar kan gebruiken om problemen tijdelijk te verbergen.

Om problemen uitvoerbaar te houden, willen we het gemakkelijker maken om te ontdekken welk deel van een pagina een probleem heeft veroorzaakt. We denken in het bijzonder na over manieren om problemen die daadwerkelijk van uw pagina afkomstig zijn (dat wil zeggen first-party) te onderscheiden en te filteren van problemen die worden veroorzaakt door bronnen die u insluit, maar die niet direct onder uw controle vallen (zoals een advertentienetwerk). Als eerste stap is het mogelijk om cookies van derden te verbergen in Chrome 86.

Als u suggesties heeft om het tabblad Problemen te verbeteren, kunt u ons dit laten weten door een bug in te dienen!

Download de voorbeeldkanalen

Overweeg om Chrome Canary , Dev of Beta te gebruiken als uw standaard ontwikkelingsbrowser. Met deze voorbeeldkanalen krijgt u toegang tot de nieuwste DevTools-functies, kunt u geavanceerde webplatform-API's testen en kunt u problemen op uw site opsporen voordat uw gebruikers dat doen!

Neem contact op met het Chrome DevTools-team

Gebruik de volgende opties om de nieuwe functies, updates of iets anders gerelateerd aan DevTools te bespreken.