2019 年の最終四半期、Chrome DevTools チームは、DevTools の Cookie に関するデベロッパー エクスペリエンスの改善に着手しました。Google Chrome や他のブラウザで Cookie のデフォルトの動作が変更され始めているため、これは特に重要です。
DevTools ですでに提供されているツールを調査していると、多くの場合、次のような状況に陥りました。
ꛭ コンソールには警告やエラー メッセージが多く、技術的な説明や chromestatus.com へのリンクが含まれていたりしました。どのメッセージもほぼ同じくらい重要に見え、最初に対処すべきメッセージがわかりにくかったのです。さらに重要なのは、テキストが DevTools 内の追加情報にリンクされていないため、何が起こったかを理解するのが難しいことです。そして最後に、問題の解決方法や、技術的なコンテキストの把握など、すべてウェブ デベロッパーに委ねられることもよくありました。
独自のアプリケーションからのメッセージにもこのコンソールを使用すると、ブラウザからのすべてのメッセージの中から目的のメッセージを見つけるのが難しいことがあります。
人間と同様に、自動化されたプロセスでコンソール メッセージとやり取りすることも困難です。たとえば、デベロッパーは継続的インテグレーション/継続的デプロイのシナリオで Chrome ヘッドレスと Puppeteer を使用することがあります。コンソール メッセージは単なる文字列であるため、実用的な情報を抽出するには、正規表現やその他のパーサーを作成する必要があります。
解決方法: 構造化された実用的な問題の報告
私たちは、発見した問題に対するより適切な解決策を見つけるために、まず要件について検討し、設計ドキュメントにまとめました。
Google では、問題の内容と解決方法を明確に説明して問題を提示することを目指しています。 設計プロセスから、各問題には以下の 4 つの要素を含める必要があることが判明しました。
- タイトル
- 説明
- DevTools 内の影響を受けるリソースへのリンク
- 詳細なガイダンスへのリンク
タイトルについては、デベロッパーが根本的な問題を理解できるように短く正確なものにします。多くの場合、修正のヒントも示されています。たとえば、Cookie の問題は次のような内容になります。
クロスサイト Cookie をセキュアとしてマークし、クロスサイト コンテキストで Cookie を設定できるようにする
それぞれの問題には、説明に詳細な情報が含まれています。何が起きたかについての説明、修正方法に関する実用的なアドバイス、DevTools 内の他のパネルへのリンク（英語）では、状況に合わせて問題を理解できます。また、ウェブ デベロッパーがこのトピックの詳細を確認できるように、web.dev にある詳細な記事へのリンクも提供されています。
各問題の重要な部分は影響を受けるリソース セクションです。このセクションは DevTools の他の部分にリンクされているため、簡単に調査できます。Cookie の問題の例では、問題の原因となったネットワーク リクエストのリストが表示されます。リクエストをクリックすると、直接 [Network] パネルが表示されます。この機能が便利なだけでなく、特定の種類の問題のデバッグに使用できる DevTools 内のパネルやツールを強化するためにも役立つことを願っています。
デベロッパーによる [問題] タブの操作について、長期的に考えると、次のように進化すると考えられます。
- ウェブ デベロッパーは、特定の問題に初めて直面したときに、問題を詳しく理解するために記事を読んでいます。
- 2 度目に問題が発生した際は、デベロッパーの皆様が問題の内容を再確認し、すぐに調査して解決に取り組めるよう、問題の説明を添えていただければと考えております。
- 何度か問題を経験した後、デベロッパーが問題の種類を認識するのに問題のタイトルだけで十分と考えております。
改善の必要なもう一つの重要な側面は、集計です。たとえば、同じ Cookie で同じ問題が複数回発生した場合に、その Cookie を 1 回だけレポートするようにします。これにより、メッセージの数を大幅に削減できるだけでなく、多くの場合、問題の根本原因をより迅速に特定できます。
実装
これらの要件を念頭に置いて、チームは新機能の実装方法を検討し始めました。通常、Chrome DevTools のプロジェクトは、次の 3 つの異なる領域にまたがっています。
- Chromium: Google Chrome の背後に C++ で作成されたオープンソース プロジェクト
- DevTools フロントエンド: Chrome DevTools の JavaScript 実装です。
- Chrome DevTools プロトコル（CDP）。これは両者をつなぐレイヤです。
その後、実装は次の 3 つのタスクで構成されていました。
- Chromium 内では、表示したい情報を持つコンポーネントを特定し、スピードやセキュリティを犠牲にすることなく、DevTools プロトコルでその情報にアクセスできるようにする必要がありました。
- 次に、DevTools フロントエンドなどのクライアントに情報を公開する API を定義するために、Chrome DevTools プロトコル（CDP）を設計する必要がありました。
- 最後に、DevTools フロントエンドにコンポーネントを実装する必要がありました。このコンポーネントは、CDP 経由でブラウザに情報をリクエストし、デベロッパーが情報を簡単に解釈して操作できるように、適切な UI に表示します。
ブラウザ側では、まずコンソール メッセージがどのように処理されるかを調べました。というのも、その動作は問題に対して考慮していたものと非常に似ているからです。通常、このようなデータ探索には CodeSearch が適しています。このツールを使用すると、Chromium プロジェクトのソースコード全体をオンラインで検索、探索できます。そうすることで、コンソール メッセージの実装について学び、問題に対して収集した要件を並行して、しかしより構造化した方法を構築できます。
ここでの作業は、常に念頭に置かなければならないセキュリティ上のあらゆる影響から、特に困難な作業です。Chromium プロジェクトは、物事を異なるプロセスに分割し、制御された通信チャネルを介してのみ通信することで情報漏洩を防ぐために大いに役立ちます。問題には機密情報が含まれることがあるため、そうした情報を、認識すべきではないブラウザ部分に送信しないように注意する必要があります。
DevTools フロントエンド
DevTools 自体は、JavaScript と CSS で記述されたウェブ アプリケーションです。10 年以上前から存在する点を除き、他の多くのウェブ アプリケーションとよく似ています。もちろん、そのバックエンドは基本的にブラウザへの直接の通信チャネル、すなわち Chrome DevTools プロトコルです。
[問題] タブでは、まずユーザー ストーリーと、デベロッパーが問題を解決するために何を行う必要があるかについて検討しました。Google のアイデアのほとんどは、[問題] タブを調査の出発点として、より詳細な情報を表示するパネルとユーザーを結びつけることから始まりました。[Issues] タブを DevTools の下部に配置し、デベロッパーが別の DevTools コンポーネント（[Network] パネルや [Application] パネルなど）を操作している間、このタブを開いたままにできるようにしました。
この点を念頭に置いて、UX デザイナーは私たちが目指していることを理解し、次の最初の提案のプロトタイプを作成しました。
最適なソリューションについて多くの議論を重ねた結果、設計の実装と決定事項を繰り返し確認した結果、現在の [問題] タブがどのようなものになるかに少しずつ着手しました。
もう 1 つの非常に重要な要素は、[問題] タブの見つけやすさです。これまでは、デベロッパーが具体的に何に注目すべきかわからなければ、Devtools の優れた機能の多くは見つけられませんでした。[問題] タブでは、デベロッパーが重要な問題を見落とすことがないよう、複数の異なる領域で問題をハイライト表示することにしました。
問題を優先して一部のコンソール メッセージが削除されるようになったため、コンソール パネルに通知を追加することにしました。また、[DevTools] ウィンドウの右上にある警告とエラーのカウンタにアイコンを追加しました。
[Issues] タブには、他の DevTools パネルにリンクされているだけでなく、問題に関連するリソースにも [Issues] タブに戻るリンクがあります。
プロトコル
フロントエンドとバックエンドの間の通信は、Chromium DevTools プロトコル（CDP）と呼ばれるプロトコルで行われます。CDP は、Chrome DevTools であるウェブアプリのバックエンドと考えることができます。CDP は複数のドメインに分割されており、各ドメインには多数のコマンドとイベントが含まれています。
[問題] タブについて、新しい問題が発生したたびにトリガーされる新しいイベントを Audits ドメインに追加することにしました。DevTools がまだ開いていないときに発生した問題を報告できるように、Audits ドメインに最新の問題が保存され、DevTools が接続されるとすぐにその問題がディスパッチされます。その後、DevTools はこれらすべての問題を収集して集計します。
CDP では、Puppeteer などの他のプロトコル クライアントでも問題を受信して処理できます。CDP で送信される構造化された問題情報により、既存の継続的インテグレーション インフラストラクチャへの統合が可能になり、簡素化されることを願っています。これにより、ページをデプロイする前に問題を検出して修正できます。
予定
まず、さらに多くのメッセージをコンソールから [問題] タブに移動する必要があります。新しい問題が追加されるたびに、明確かつ実用的なドキュメントを提供したいと考えています。そのため、この作業には時間がかかります。今後、デベロッパーの皆様がコンソールではなく [問題] タブで問題を探すようになることを願っております。
また、Chromium バックエンド以外のソースで発生した問題を [問題] タブに統合する方法も検討中です。
[問題] タブを整理し、ユーザビリティを改善する方法を現在検討中です。今年は、検索、フィルタリング、より優れた集計機能が用意されています。報告される問題の増加を体系化するために、問題カテゴリを導入する作業を進めています。たとえば、今後サポートの終了が予定される問題のみを表示できるようになります。また、デベロッパーが問題を一時的に非表示にできるスヌーズ機能の追加も検討しています。
問題を対応可能にするため、Google はページのどの部分が問題を引き起こしたかを簡単に特定できるようにしたいと考えています。具体的には、お客様のページ（自社）に実際に生じた問題と、お客様が埋め込みリソースによって引き起こされたが直接管理下にない問題（広告ネットワークなど）とを区別し、フィルタする方法を検討しています。まず、Chrome 86 でサードパーティ Cookie の問題を非表示にできるようになります。
[問題] タブの改善についてご提案がありましたら、バグとしてお知らせください。
プレビュー チャネルをダウンロードする
Chrome Canary、Dev、Beta を既定の開発ブラウザとして使用することをご検討ください。これらのプレビュー チャンネルでは、最新の DevTools 機能にアクセスしたり、最先端のウェブ プラットフォーム API をテストしたり、ユーザーが実際に体験する前にサイト上の問題を検出したりできます。
Chrome DevTools チームへのお問い合わせ
投稿内の新機能や変更点、または DevTools に関するその他のことについて話し合うには、次のオプションを使用します。
- crbug.com からご提案やフィードバックをお送りください。
- DevTools の問題を報告するには、DevTools でその他のオプション アイコン
> [ヘルプ] > [DevTools の問題を報告する] を選択します。 - @ChromeDevTools にツイートします。
- 「DevTools の新機能」の YouTube 動画または DevTools のヒントの YouTube 動画でコメントを残してください。