Как мы создали вкладку «Проблемы Chrome DevTools»

Ян Шеффлер
Jan Scheffler
Сигурд Шнайдер
Sigurd Schneider
X

В последнем квартале 2019 года команда Chrome DevTools начала улучшать возможности разработчиков DevTools в отношении файлов cookie. Это было особенно важно, поскольку Google Chrome и другие браузеры начали менять поведение файлов cookie по умолчанию.

Исследуя инструменты, которые уже предоставляет DevTools, мы часто оказывались в такой ситуации:

Проблемы на панели консоли

😰 Консоль была полна предупреждений и сообщений об ошибках, которые содержали скорее технические пояснения, а иногда и ссылки на chromestatus.com . Все сообщения выглядели примерно одинаково важными, поэтому было трудно понять , к кому обратиться в первую очередь . Что еще более важно, текст не ссылался на дополнительную информацию внутри DevTools, что затрудняло понимание того, что произошло . И, наконец, сообщения часто оставляли веб-разработчику возможность выяснить, как решить проблему , или даже узнать о техническом контексте.

Если вы также используете консоль для сообщений из своего приложения, иногда вам будет сложно найти их среди всех сообщений браузера.

Автоматизированным процессам, как и людям, сложно взаимодействовать с сообщениями консоли. Например, разработчики могут использовать Chrome Headless и Puppeteer в сценарии непрерывной интеграции/непрерывного развертывания. Поскольку сообщения консоли представляют собой просто строки, разработчикам необходимо писать регулярные выражения или какой-либо другой синтаксический анализатор для извлечения полезной информации.

Решение: структурированные и действенные отчеты о проблемах

Чтобы найти лучшее решение обнаруженных нами проблем, мы сначала начали думать о требованиях и собрали их в Design Doc .

Наша цель – представить проблемы таким образом, чтобы четко объяснить суть проблемы и способы ее решения . В процессе проектирования мы поняли, что каждый выпуск должен состоять из следующих четырех частей:

  • Заголовок
  • Описание
  • Ссылки на затронутые ресурсы в DevTools
  • И ссылка на дальнейшее руководство

Что касается названия, мы хотим, чтобы оно было коротким и точным, чтобы помочь разработчикам понять основную проблему, и часто уже намекало на решение. Например, проблема с файлами cookie теперь выглядит просто:

Отметьте межсайтовые файлы cookie как безопасные, чтобы разрешить их настройку в межсайтовом контексте.

Каждая проблема содержит более подробную информацию в описании, в котором объясняется, что произошло , даются практические советы о том, как ее исправить, а также ссылки на другие панели внутри DevTools, чтобы понять проблему в контексте. Мы также предоставляем ссылки на подробные статьи на web.dev , чтобы веб-разработчики могли более подробно изучить эту тему.

Важной частью каждой проблемы является раздел затронутых ресурсов , который связан с другими частями DevTools и упрощает дальнейшее исследование. Для примера проблемы с файлами cookie должен быть список сетевых запросов, вызвавших проблему, и нажатие на запрос напрямую приведет вас к панели «Сеть». Мы надеемся, что это не только удобно, но и укажет, какие панели и инструменты внутри DevTools можно использовать для устранения проблем определенного типа.

Рассматривая взаимодействие разработчиков с вкладкой «Проблемы» в долгосрочной перспективе, мы представляем следующую эволюцию взаимодействия разработчиков:

  • Впервые сталкиваясь с определенной проблемой, веб-разработчик читал статью, чтобы глубже понять проблему.
  • Мы надеемся, что при возникновении проблемы во второй раз описания проблемы будет достаточно, чтобы напомнить разработчику о том, в чем заключалась проблема, и позволить им немедленно изучить ее и принять меры для ее решения.
  • После того, как мы столкнулись с проблемой несколько раз, мы надеемся, что названия проблемы будет достаточно, чтобы разработчик мог распознать тип проблемы.

Еще один важный аспект, который мы хотели улучшить, — это агрегация . Например, если один и тот же файл cookie несколько раз вызывал одну и ту же проблему, мы хотели сообщить об этом файле cookie только один раз. Помимо значительного сокращения количества сообщений, это часто помогает быстрее определить основную причину проблемы.

Совокупные проблемы

Реализация

Принимая во внимание эти требования, команда начала искать способы реализации новой функции. Проекты для Chrome DevTools обычно охватывают три разные области:

Тогда реализация включала в себя три задачи:

  • Внутри Chromium нам нужно было определить компоненты, содержащие информацию, которую мы хотим раскрыть, и сделать эту информацию доступной для протокола DevTools без ущерба для скорости и безопасности.
  • Затем нам нужно было разработать протокол Chrome DevTools (CDP) для определения API, который предоставляет информацию клиентам, например интерфейсу DevTools.
  • Наконец, нам нужно было реализовать в интерфейсе DevTools компонент, который запрашивает информацию из браузера через CDP и отображает ее в соответствующем пользовательском интерфейсе, чтобы разработчики могли легко интерпретировать информацию и взаимодействовать с ней.

Что касается браузера, мы сначала изучили, как обрабатываются консольные сообщения, поскольку их поведение очень похоже на то, что мы имели в виду для проблем. CodeSearch обычно является хорошей отправной точкой для подобных исследований. Он позволяет вам искать и изучать весь исходный код проекта Chromium в Интернете. Таким образом, мы узнали о реализации консольных сообщений и смогли создать параллельный, но более структурированный способ решения проблем, которые мы собрали для решения проблем.

Работа здесь особенно сложна из-за всех последствий безопасности, которые мы всегда должны иметь в виду. Проект Chromium имеет большое значение для разделения вещей на разные процессы и обеспечения их взаимодействия только через контролируемые каналы связи, чтобы предотвратить утечку информации. Проблемы могут содержать конфиденциальную информацию, поэтому мы должны позаботиться о том, чтобы не отправить эту информацию в ту часть браузера, которая не должна о ней знать.

В интерфейсе DevTools

DevTools сам по себе представляет собой веб-приложение, написанное на JavaScript и CSS. Оно во многом похоже на многие другие веб-приложения, за исключением того, что оно существует уже более 10 лет. И, конечно же, его серверная часть — это, по сути, прямой канал связи с браузером: протокол Chrome DevTools.

Что касается вкладки «Проблемы», мы сначала подумали о пользовательских историях и о том, что разработчикам придется сделать, чтобы решить проблему. Наши идеи в основном развивались вокруг вкладки «Проблемы» в качестве центральной отправной точки для расследований, которые связывали людей с панелями, показывающими более подробную информацию. Мы решили разместить вкладку «Проблемы» вместе с другими вкладками в нижней части DevTools, чтобы она могла оставаться открытой, пока разработчик взаимодействует с другим компонентом DevTools, например с панелью «Сеть» или «Приложение».

Имея это в виду, наш UX-дизайнер понял, к чему мы стремимся, и создал прототип следующих первоначальных предложений:

Прототипы

После долгих обсуждений лучшего решения мы начали реализовывать дизайн и повторять решения, чтобы постепенно прийти к тому, как вкладка «Проблемы» выглядит сегодня.

Еще одним очень важным фактором была доступность вкладки «Проблемы». В прошлом многие замечательные функции Devtools нельзя было обнаружить, если разработчик не знал, что именно искать. На вкладке «Проблемы» мы решили выделить проблемы в нескольких различных областях, чтобы разработчики не пропустили важные проблемы.

Мы решили добавить уведомление на панель консоли, поскольку некоторые сообщения консоли теперь удалены в пользу проблем. Мы также добавили значок к счетчику предупреждений и ошибок в правом верхнем углу окна DevTools.

Уведомление о проблемах

Наконец, вкладка «Проблемы» не только связана с другими панелями DevTools, но и ресурсы, связанные с проблемой, также ссылаются на вкладку «Проблемы».

Связанные вопросы

В протоколе

Связь между интерфейсом и сервером осуществляется по протоколу Chromium DevTools Protocol (CDP). CDP можно рассматривать как серверную часть веб-приложения Chrome DevTools. CDP разделен на несколько доменов, и каждый домен содержит ряд команд и событий.

Для вкладки «Проблемы» мы решили добавить в домен «Аудит» новое событие , которое срабатывает при возникновении новой проблемы. Чтобы мы также могли сообщать о проблемах, возникающих, пока DevTools еще не открыт, домен Audits хранит самые последние проблемы и отправляет их, как только DevTools подключается. Затем DevTools собирает все эти проблемы и объединяет их.

CDP также позволяет другим клиентам протокола, таким как Puppeteer , получать и обрабатывать проблемы. Мы надеемся, что структурированная информация о проблемах, отправленная через CDP, позволит и упростит интеграцию в существующую инфраструктуру непрерывной интеграции. Таким образом, проблемы можно обнаружить и устранить еще до развертывания страницы!

Будущее

Прежде всего, гораздо больше сообщений приходится перемещать с консоли на вкладку «Проблемы». Это займет некоторое время, особенно потому, что мы хотим предоставлять четкую и полезную документацию для каждой новой проблемы, которую мы добавляем. Мы надеемся, что в будущем разработчики будут искать проблемы на вкладке «Проблемы», а не в консоли!

Кроме того, мы думаем, как интегрировать проблемы из других источников, помимо серверной части Chromium, на вкладку «Проблемы».

Мы ищем способы сохранить порядок на вкладке «Проблемы» и повысить удобство использования. Поиск, фильтрация и улучшенное агрегирование — в нашем списке на этот год. Чтобы структурировать растущее число сообщаемых проблем, мы находимся в процессе введения категорий проблем, которые, например, позволят отображать только проблемы, связанные с предстоящим прекращением поддержки. Мы также думаем о добавлении функции повтора, которую разработчик может использовать для временного скрытия проблем.

Чтобы проблемы оставались актуальными, мы хотим упростить определение того, какая часть страницы вызвала проблему. В частности, мы думаем о том, как отличать и фильтровать проблемы, которые действительно исходят от вашей страницы (т. е. собственные), от проблем, которые вызваны встраиваемыми вами ресурсами, но не находятся под вашим прямым контролем (например, рекламной сетью). В качестве первого шага в Chrome 86 можно будет скрыть проблемы со сторонними файлами cookie.

Если у вас есть предложения по улучшению вкладки «Проблемы», сообщите нам об этом, сообщив об ошибке !

Загрузите предварительный просмотр каналов

Рассмотрите возможность использования Chrome Canary , Dev или Beta в качестве браузера для разработки по умолчанию. Эти каналы предварительного просмотра предоставляют вам доступ к новейшим функциям DevTools, позволяют тестировать передовые API-интерфейсы веб-платформы и помогают находить проблемы на вашем сайте раньше, чем это сделают ваши пользователи!

Свяжитесь с командой Chrome DevTools

Используйте следующие параметры, чтобы обсудить новые функции, обновления или что-либо еще, связанное с DevTools.