W ostatnim kwartale 2019 r. zespół Narzędzi deweloperskich w Chrome rozpoczął ulepszanie obsługi plików cookie w tych narzędziach. Było to szczególnie ważne, ponieważ Google Chrome i inne przeglądarki zaczęły zmieniać domyślne zachowanie plików cookie.
Podczas badania narzędzi, które są już dostępne w DevTools, często trafialiśmy na taką sytuację:
😰 Konsola była pełna ostrzeżeń i komunikatów o błędach, które zawierały wyjaśnienia techniczne i czasem prowadziły do strony chromestatus.com. Wszystkie komunikaty wyglądały mniej więcej tak samo ważne, co utrudniało podjęcie decyzji, które z nich trzeba rozwiązać w pierwszej kolejności. Co ważniejsze, tekst nie zawierał linku do dodatkowych informacji w DevTools, co utrudniało zrozumienie tego, co się stało. W końcu wiadomości często pozostawiały programistom internetowym całkowitą odpowiedzialność za rozwiązanie problemu czy nawet zapoznanie się z kontekstem technicznym.
Jeśli konsoli używasz też do wiadomości z własnej aplikacji, czasami trudno będzie je znaleźć wśród wszystkich wiadomości z przeglądarki.
Podobnie jak w przypadku ludzi, automatyczne procesy również mają trudności z obsługą wiadomości w konsoli. Na przykład programiści mogą używać przeglądarki Chrome Headless i Puppeteer w ramach ciągłej integracji lub ciągłego wdrażania. Ponieważ komunikaty konsoli to tylko ciągi znaków, deweloperzy muszą pisać wyrażenia regularne lub używać innych parserów, aby wyodrębnić przydatne informacje.
Rozwiązanie: uporządkowane i przydatne raportowanie problemów
Aby znaleźć lepsze rozwiązanie dla znalezionych problemów, zaczęliśmy od przeanalizowania wymagań i zebrania ich w dokumentacji projektowej.
Naszym celem jest prezentowanie problemów w sposób, który dokładnie wyjaśnia problem i jak go rozwiązać. Podczas procesu projektowania stwierdziliśmy, że każdy artykuł powinien zawierać 4 części:
- Tytuł
- Opis
- Linki do zasobów, których dotyczy problem, w Narzędziach deweloperskich
- oraz link do dalszych wskazówek.
Chcemy, aby tytuł był krótki i precyzyjny, aby pomóc deweloperom zrozumieć istotę problemu. Często zawiera też wskazówki dotyczące rozwiązania. Na przykład problem z plikami cookie wygląda teraz tak:
Oznacz pliki cookie z innych witryn jako bezpieczne, aby umożliwić ich ustawienie w kontekście wielu witryn
Każdy problem zawiera bardziej szczegółowe informacje, które wyjaśniają, co się stało, i umożliwiają podejmowanie działań do rozwiązania problemu. Dodatkowo linki do innych paneli w Narzędziach deweloperskich pozwalają zrozumieć problem w kontekście. Udostępniamy też linki do szczegółowych artykułów w web.dev, aby programiści webowi mogli dowiedzieć się więcej na dany temat.
Ważną częścią każdego problemu jest sekcja Zasoby, na które wpływa problem, która zawiera linki do innych części Narzędzi deweloperskich i ułatwia dalsze analizowanie problemu. W przypadku problemu z plikami cookie powinna się wyświetlić lista żądań sieciowych, które spowodowały problem. Kliknięcie żądania spowoduje przejście do panelu Sieć. Mamy nadzieję, że nie tylko jest to wygodne, ale też ułatwia zrozumienie, których paneli i narzędzi w narzędziach deweloperskich można używać do debugowania określonych problemów.
Jeśli chodzi o długoterminowe interakcje deweloperów z kartą Problemy, wyobrażamy sobie taką ewolucję:
- Gdy po raz pierwszy napotkasz konkretny problem, programista stron internetowych powinien przeczytać artykuł, aby dogłębnie go zrozumieć.
- Mamy nadzieję, że po napotkaniu problemu po raz drugi, mamy nadzieję, że jego opis przypomni deweloperowi, na czym polega problem, i pozwoli od razu go zbadać i podjąć działania w celu jego rozwiązania.
- Po kilkukrotnym napotkaniu problemu mamy nadzieję, że tytuł problemu wystarczy deweloperowi do rozpoznania jego typu.
Kolejnym ważnym aspektem, który chcemy ulepszyć, jest agregacja. Jeżeli na przykład ten sam plik cookie wielokrotnie powoduje ten sam problem, chcemy zgłosić go tylko raz. Pozwala to znacznie zmniejszyć liczbę wiadomości i często pomaga szybciej zidentyfikować główną przyczynę problemu.
Implementacja
Mając na uwadze te wymagania, zespół zaczął szukać sposobu na wdrożenie nowej funkcji. Projekty w Narzędziach deweloperskich w Chrome zwykle obejmują 3 obszary:
- Chromium, projekt open source napisany w C++, który jest podstawą Google Chrome
- Frontend narzędzi deweloperskich, czyli implementacja narzędzi deweloperskich w Chrome w języku JavaScript.
- protokół narzędzi deweloperskich w Chrome (CDP), który łączy te dwa elementy;
Następnie wdrożenie obejmowało 3 zadania:
- W Chromium musieliśmy zidentyfikować komponenty zawierające odpowiednie informacje i udostępnić je za pomocą protokołu Narzędzi deweloperskich bez szkody dla szybkości i bezpieczeństwa.
- Następnie musieliśmy zaprojektować protokół Chrome DevTools Protocol (CDP), aby zdefiniować interfejs API, który udostępnia informacje klientom, takim jak interfejs front-end Narzędzi dla programistów.
- Na koniec musieliśmy wdrożyć w frontendzie Narzędzi deweloperskich komponent, który wysyła do przeglądarki żądanie informacji z przeglądarki przez CDP i wyświetla je w odpowiednim interfejsie, tak aby programiści mogli łatwo zinterpretować te informacje i wchodzić z nimi w interakcję.
W przypadku przeglądarki najpierw przyjrzeliśmy się temu, jak obsługiwane są wiadomości w konsoli, ponieważ ich działanie jest bardzo podobne do tego, co mieliśmy na myśli w przypadku problemów. CodeSearch jest zwykle dobrym punktem wyjścia do takich eksploracji. Umożliwia wyszukiwanie i przeglądanie całego kodu źródłowego projektu Chromium online. Dzięki temu dowiedzieliśmy się więcej o wdrożeniu wiadomości w konsoli i mogliśmy stworzyć równoległy, ale bardziej uporządkowany sposób na podstawie wymagań zebranych w związku z problemami.
Jest to szczególnie trudne zadanie, ponieważ musimy zawsze mieć na uwadze wszystkie aspekty bezpieczeństwa. W projekcie Chromium można bardzo podzielić elementy na różne procesy i umożliwić im komunikowanie się tylko przez kontrolowane kanały komunikacji, co zapobiega wyciekom informacji. Problemy mogą zawierać informacje poufne, dlatego musimy uważać, aby nie wysyłać tych informacji do części przeglądarki, która ich nie potrzebuje.
Frontend w Narzędziach deweloperskich
DevTools to aplikacja internetowa napisana w języku JavaScript i CSS. Jest bardzo podobna do wielu innych aplikacji internetowych, z tym wyjątkiem, że istnieje już od ponad 10 lat. Oczywiście jego backend to w podstawie kanał komunikacji z przeglądarką: protokół narzędzi deweloperskich w Chrome.
W przypadku karty Problemy najpierw zastanowiliśmy się nad scenariuszami użytkownika i tym, co deweloperzy musieliby zrobić, aby rozwiązać problem. Nasze pomysły koncentrowały się głównie na karcie Problemy jako centralnym punkcie początkowym badań, który kieruje użytkowników do paneli z bardziej szczegółowymi informacjami. Zdecydowaliśmy się umieścić kartę Problemy wraz z innymi kartami u dołu Narzędzi deweloperskich, aby pozostawała otwarta, gdy deweloper wejdzie w interakcję z innym komponentem Narzędzi deweloperskich, na przykład siecią lub panelem Aplikacja.
Mając to na uwadze, nasz projektant UX zrozumiał, czego oczekujemy, i utworzył prototypy tych wstępnych propozycji:
Po wielu dyskusjach na temat najlepszego rozwiązania zaczęliśmy wdrażać projekt i powtarzać decyzje, aby stopniowo dojść do tego, jak obecnie wygląda karta Problemy.
Kolejnym bardzo ważnym czynnikiem była wykrywalność karty Problemy. W przeszłości wiele świetnych funkcji Devtools nie było żadnych możliwych, gdyby deweloper nie wiedział, czego konkretnie szukać. Na karcie Problemy postanowiliśmy wyróżnić problemy w różnych obszarach, aby deweloperzy nie pomijali ważnych problemów.
Postanowiliśmy dodać powiadomienie do panelu konsoli, ponieważ niektóre komunikaty konsoli zostały usunięte na rzecz problemów. Dodaliśmy też ikonę do licznika ostrzeżeń i błędów w prawym górnym rogu okna Narzędzi deweloperskich.
Karta Problemy zawiera nie tylko linki do innych paneli w Narzędziach deweloperskich, ale też do karty Problemy.
W protokole
Komunikacja między frontendem a backendem odbywa się za pomocą protokołu Chromium DevTools Protocol (CDP). CDP można określić jako backend aplikacji internetowej Chrome DevNarzędzia. CDP jest podzielony na wiele domen, a każda z nich zawiera określoną liczbę poleceń i zdarzeń.
W przypadku karty Problemy zdecydowaliśmy się dodać do domeny Audyt nowe zdarzenie, które uruchamia się, gdy pojawi się nowy problem. Abyśmy mogli też zgłaszać problemy, które pojawiają się, gdy Narzędzia deweloperskie nie są jeszcze otwarte, domena Audits przechowuje najnowsze problemy i wysyła je, gdy tylko Narzędzia deweloperskie się połączą. Narzędzie DevTools zbiera wszystkie te problemy i je agreguje.
CDP umożliwia też innym klientom protokołu, takim jak Puppeteer, odbieranie i przetwarzanie problemów. Mamy nadzieję, że uporządkowane informacje o problemach przesyłane przez CDP pozwolą na uproszczenie integracji z dotychczasową infrastrukturą ciągłej integracji. Dzięki temu problemy mogą zostać wykryte i rozwiązane jeszcze przed wdrożeniem strony.
Przyszła
Po pierwsze, z konsoli na kartę Problemy trzeba przenieść znacznie więcej wiadomości. Zajmie to trochę czasu, zwłaszcza że chcemy zapewnić czytelną i użyteczną dokumentację dla każdego nowego problemu. Mamy nadzieję, że w przyszłości deweloperzy będą szukać problemów na karcie Problemy, a nie w konsoli.
Poza tym zastanawiamy się, jak dodać na karcie Problemy problemy z innych źródeł (oprócz backendu Chromium).
Szukamy sposobów na uporządkowanie zakładki Problemy i poprawę jej użyteczności. W tym roku planujemy wprowadzić m.in. wyszukiwanie, filtrowanie i lepszą agregację. Aby uporządkować rosnącą liczbę zgłaszanych problemów, wprowadzamy kategorie problemów, które umożliwią np. wyświetlanie tylko problemów dotyczących nadchodzących wycofań. Rozważamy też dodanie funkcji odłożenia, która pozwoli deweloperom tymczasowo ukryć problemy.
Aby ułatwić rozwiązywanie problemów, chcemy ułatwić Ci ustalenie, która część strony spowodowała problem. Rozważamy w szczególności sposoby rozróżniania i filtrowania problemów, które pochodzą bezpośrednio z Twojej strony (czyli od Ciebie), od problemów wywołanych przez zaimplementowane przez Ciebie zasoby, ale nie podlegających Twojej bezpośredniej kontroli (np. sieć reklamowa). Pierwszym krokiem będzie możliwość ukrywania problemów z plikami cookie innych firm w Chrome 86.
Jeśli masz sugestie dotyczące ulepszenia karty Problemy, prosimy o poinformowanie nas o tym, zgłaszając błąd.
Pobieranie kanałów podglądu
Rozważ użycie przeglądarki Chrome Canary, Dev lub Beta jako domyślnej przeglądarki deweloperskiej. Te kanały wersji testowej dają dostęp do najnowszych funkcji Narzędzi deweloperskich, umożliwiają testowanie najnowocześniejszych interfejsów API platform internetowych i pomagają w wykrywaniu problemów w witrynie przed użytkownikami.
Kontakt z zespołem Narzędzi deweloperskich w Chrome
Aby omówić nowe funkcje, aktualizacje lub inne kwestie związane z Narzędziami deweloperskimi, skorzystaj z tych opcji.
- Przesyłaj opinie i prośby o dodanie funkcji na stronie crbug.com.
- Zgłoś problem z Narzędziami deweloperskimi, klikając Więcej opcji > Pomoc > Zgłoś problem z Narzędziami deweloperskimi.
- Wyślij tweeta do @ChromeDevTools.
- Dodaj komentarze do filmów w YouTube z serii „Co nowego w Narzędziach deweloperskich” lub Wskazówki dotyczące Narzędzi deweloperskich.