我们如何构建 Chrome 开发者工具的“问题”标签页

Jan Scheffler
Jan Scheffler
Sigurd Schneider
Sigurd Schneider
X

在 2019 年的最后一个季度，Chrome 开发者工具团队开始改进 DevTools 中与 Cookie 相关的开发者体验。这一点尤为重要，因为 Google Chrome 和其他浏览器已开始更改其默认 Cookie 行为。

在研究 DevTools 已提供的工具时，我们经常会遇到以下情况：

控制台面板中的问题

😰? 控制台上充斥着警告和错误消息，其中包含相当专业的说明，有时还会提供指向 chromestatus.com 的链接。所有消息看起来都差不多一样重要，因此很难确定应先解决哪个消息。更重要的是，文本没有链接到开发者工具中的其他信息，导致难以理解所发生的情况。最后，这类消息往往完全留给 Web 开发者去解决如何解决问题，甚至完全留给自己了解技术背景。

如果您还使用该控制台查看来自您自己应用的消息，那么在浏览器中的所有消息中，有时会很难找到这些消息。

除了人类之外，自动化流程也难以与控制台消息互动。例如，开发者可能会在持续集成/持续部署场景中使用 Chrome Headless 和 Puppeteer。由于控制台消息只是字符串，因此开发者需要编写正则表达式或其他一些解析器，才能提取可操作的信息。

解决方案：结构化且富有实用价值的问题报告

为了更好地解决我们发现的问题，我们首先考虑了相关要求，并将其收集到设计文档中。

我们的目标是，以清晰的方式说明问题以及如何解决问题。 在设计过程中，我们发现每个问题都应包含以下四个部分：

  • 标题
  • 说明
  • 指向 DevTools 中受影响资源的链接
  • 以及指向进一步指导的链接

标题应简洁明了，以帮助开发者了解核心问题，并且通常已经暗示了解决方法。例如，Cookie 问题现在只会显示以下内容：

将跨网站 Cookie 标记为“安全”，以允许在跨网站上下文中设置这些 Cookie

每个问题的说明中都包含更多详细信息，其中说明了发生了什么，提供了有关如何解决问题的切实可行的建议，以及指向 DevTools 中其他面板的链接，以便您在上下文中了解问题。我们还提供了指向 web.dev 上深度文章的链接，以便 Web 开发者更详细地了解该主题。

每个问题的重要部分是受影响的资源部分，其中包含指向开发者工具其他部分的链接，可让您轻松进行进一步调查。例如，在 Cookie 问题示例中，您应该会看到触发该问题的网络请求列表，点击相应请求即可直接前往“网络”面板。我们希望这不仅能让您更轻松地使用，还能让您更清楚地了解 DevTools 中哪些面板和工具可用于调试特定类型的问题。

从长远来看，我们预计开发者与“问题”标签页的互动将会经历以下演变：

  • 当 Web 开发者首次遇到特定问题时，会阅读相关文章，以深入了解该问题。
  • 当第二次遇到该问题时，我们希望问题说明足以提醒开发者该问题的具体内容，并让他们能够立即进行调查并采取措施来解决该问题。
  • 我们希望在开发者遇到某个问题几次后，问题标题就足以让他们识别出问题类型。

我们还希望改进另一个重要方面，即汇总。例如，如果同一 Cookie 多次导致同一问题，我们希望只报告一次该 Cookie。除了大大减少消息数量之外，这通常还有助于更快地找出问题的根本原因。

汇总问题

实现

有了这些要求，该团队开始研究如何实现新功能。Chrome 开发者工具的项目通常涵盖三个不同的领域：

实现过程则由以下三项任务组成：

  • 在 Chromium 中，我们必须找出包含我们想要显示的信息的组件，并确保这些信息可通过开发者工具协议访问，同时又不影响速度和安全性。
  • 然后，我们需要设计 Chrome DevTools Protocol (CDP)，以定义向客户端（例如 DevTools 前端）公开信息的 API。
  • 最后，我们需要在 DevTools frontend 中实现一个组件，通过 CDP 从浏览器请求信息，并将其显示在适当的界面中，以便开发者轻松解释信息并与之互动。

对于浏览器端，我们首先研究了控制台消息的处理方式，因为其行为与我们预期的错误非常相似。在进行这类探索时，通常可以先使用 CodeSearch 进行搜索。借助此工具，您可以在线搜索和浏览 Chromium 项目的完整源代码。这样，我们就了解了控制台消息的实现方式，并能够围绕我们为问题收集的要求，构建并行但更有条理的方式。

由于我们始终要时刻谨记所有安全隐患，因此这项工作极具挑战性。Chromium 项目在很大程度上推动了将组件分离到不同进程中，并让它们仅通过受控的通信渠道进行通信，以防止信息泄露。问题可能包含敏感信息，因此我们必须注意，不要将这些信息发送到不应知道这些信息的浏览器部分。

在 DevTools 前端

DevTools 本身就是一个使用 JavaScript 和 CSS 编写的 Web 应用。它与许多其他 Web 应用非常相似，只不过它已存在 10 多年了。当然，其后端基本上是与浏览器的直接通信渠道：Chrome DevTools 协议。

对于“问题”标签页，我们首先考虑的是用户故事，以及开发者必须执行哪些操作才能解决问题。我们最初的想法大多是将“问题”标签页作为调查的中心起点，将人们与显示更多详细信息的面板联系起来。我们决定将“问题”标签页与其他标签页一起放在 DevTools 底部，以便在开发者与其他 DevTools 组件（例如“Network”或“Application”面板）互动时，该标签页保持打开状态。

有鉴于此，我们的用户体验设计师了解了我们的目标，并制作了以下初始方案的原型：

原型

在围绕最佳解决方案进行了大量讨论后，我们开始实施设计并反复推敲决策，最终逐渐确定了“问题”标签页的现有外观。

另一个非常重要的因素是“问题”标签页的可检测性。过去，如果开发者不知道具体要查找什么，就无法发现许多出色的 DevTools 功能。对于“问题”标签页，我们决定突出显示多个不同领域的问题，以确保开发者不会错过重要问题。

我们决定在控制台面板中添加一条通知，因为控制台中的部分消息现已被移除，以解决相关问题。我们还向开发者工具窗口右上角的警告和错误计数器添加了一个图标。

问题通知

最后，“Issues”（问题）标签页不仅会链接到其他开发者工具面板，还会链接到“Issues”（问题）标签页。

相关问题

在该协议中

前端和后端之间的通信通过名为 Chromium 开发者工具协议 (CDP) 的协议进行。CDP 可以看作是 Chrome 开发者工具的 Web 应用的后端。CDP 细分为多个网域，每个网域包含多个命令和事件。

对于“问题”标签页，我们决定向“审核”网域添加一个新事件，以便在遇到新问题时触发该事件。为确保我们也能报告在开发者工具未打开时出现的问题，审计网域会存储最新问题，并在开发者工具连接后立即分派这些问题。然后，DevTools 会收集所有这些问题并对其进行汇总。

CDP 还支持其他协议客户端（例如 Puppeteer）接收和处理问题。我们希望通过 CDP 发送的结构化问题信息能够实现并简化与现有持续集成基础架构的集成。这样，您甚至可以在网页部署之前检测和解决问题！

未来

首先，更多消息必须从控制台移至“问题”标签页。这需要一些时间，特别是因为我们希望为我们添加的每一个新问题提供清晰、可操作的文档。我们希望日后开发者会在“问题”标签页（而非控制台）中查找问题！

此外，我们还在考虑如何将 Chromium 后端以外的其他来源的问题集成到“问题”标签页中。

我们正在研究如何保持“问题”标签页的整洁有序，并提高其易用性。今年，我们将推出搜索、过滤和更好的汇总功能。为了对日益增多的报告问题进行分类，我们正在引入问题类别，例如，这样您就可以仅显示与即将弃用相关的问题。我们还考虑添加一个暂停功能，供开发者暂时隐藏问题。

为了让问题更具实用性，我们希望您能更轻松地发现网页的哪个部分引发了问题。具体而言，我们正在考虑如何区分和过滤真正来自您网页的问题（即第一方问题）与由您嵌入但不受您直接控制的资源（例如广告网络）触发的问题。首先，您可以在 Chrome 86 中隐藏第三方 Cookie 问题。

如果您有任何关于改进“问题”标签页的建议，请提交 bug 告诉我们！

下载预览渠道

不妨考虑将 Chrome Canary 版、开发者版或 Beta 版用作默认开发浏览器。通过这些预览版渠道，您可以使用最新的 DevTools 功能、测试尖端的 Web 平台 API，并帮助您在用户发现问题之前发现网站上的问题！

与 Chrome 开发者工具团队联系

使用以下选项讨论新功能、更新或与开发者工具相关的任何其他内容。