特に記載のない限り、下記の変更は Android、Chrome OS、Linux、macOS、Windows 向けの最新の Chrome ベータ版チャンネル リリースに適用されます。ここに記載されている機能の詳細については、リンクまたは ChromeStatus.com の一覧でご確認ください。2022 年 3 月 3 日時点で、Chrome 100 はベータ版です。PC 向けの最新版は Google.com で、Android では Google Play ストアでダウンロードできます。
Chromium 100 は、デフォルトで長い User-Agent 文字列をサポートする最後のバージョンとなる予定です（これに関連する navigator.userAgent、navigator.appVersion、navigator.platform DOM API も同様です）。サイトで完全削減版の User-Agent をテストできるようにするオリジン トライアルは、2022 年 4 月 19 日に終了します。この日以降、User-Agent 文字列は徐々に削減されます。全体スケジュールを確認したい方は、Chromium ブログ : User-Agent 削減のオリジン トライアルと日付についてをご覧ください。サイトでのテストや User-Agent Client Hints への移行にさらに時間が必要な場合は、Chrome 100 から 113（100 と 113 を含めて）で予定されている逆オリジン トライアルに登録できます。完全削減版の User-Agent 文字列を試す最初のオリジン トライアルとは異なり、逆トライアルでは以前の User-Agent が保持されます。逆トライアルは、2023 年 5 月後半に終了する予定です。
navigator.userAgent
navigator.appVersion
navigator.platform
これは、User-Agent 文字列を 新しい User-Agent Client Hints API に置き換える戦略の一環として行われます。User-Agent Client Hints の詳細については、User-Agent Client Hints に移行すると User-Agent Client Hints でユーザーのプライバシーとデベロッパーのエクスペリエンスを改善するをご覧ください。
PC で利用できるようになるマルチスクリーン ウィンドウ配置 API を使うと、マシンに接続されているディスプレイを列挙し、ウィンドウを特定の画面に配置できます。これにより、特定のウィンドウを厳密に配置する必要があるマルチウィンドウ アプリケーションなどのユースケースを実現できます。さらに、Element.requestFullscreen() メソッドに新しい screen オプションが追加され、どの画面で全画面表示を始めるかを指定できるようになります。
Element.requestFullscreen()
screen
詳細については、マルチスクリーン ウィンドウ配置 API で複数のディスプレイを管理するをご覧ください。
このバージョンの Chrome には、以下のオリジン トライアルが導入されています。オリジン トライアルとして新機能を試せるようにすることで、ウェブ標準コミュニティにユーザビリティ、実用性、有効性についてのフィードバックを提供することができます。以下の項目を含め、現在 Chrome でサポートされているオリジン トライアルに登録するには、Chrome オリジン トライアル ダッシュボードをご覧ください。Chrome のオリジン トライアルの詳細については、ウェブ デベロッパーのためのオリジン トライアル ガイドをご覧ください。Microsoft Edge は、Chrome とは別に独自のオリジン トライアルを行っています。詳細については、Microsoft Edge オリジン トライアル デベロッパー コンソールをご覧ください。
次のオリジン トライアルは、記載されているバージョンまで延長されます。
専用のワーカーから Media Source Extensions（MSE）API を利用できるようにするためのオリジン トライアルが継続されます。この機能により、メイン ウィンドウの HTMLMediaElement で再生中のメディアをバッファリングする際のパフォーマンスが向上します。アプリケーションは、専用ワーカーで MediaSource オブジェクトを作成した後、そのオブジェクト用の ObjectURL を作成できます。次に、postMessage() を呼び出してその URL をメインスレッドに渡し、HTMLMediaElement にアタッチします。すると、MediaSource オブジェクトを作成したコンテキストからメディアをバッファリングできます。ウェブ制作者からは、ワーカーのコンテキストから MSE を利用したいというリクエストが継続的に寄せられています。このオリジン トライアルの延長は、2022 年 7 月後半の Chrome 103 までとなる予定です。
HTMLMediaElement
MediaSource
postMessage()
Chrome で以前にオリジン トライアルが行われていた以下の機能は、現在デフォルトで有効化されています。
ウェブ アプリケーションからのアプリ内購入を促進するため、Chrome でデジタル商品の照会や管理をする API が提供されます。この新しい API は、実際の購入処理に使われる Payment Request API と連携して動作します。この API は、ユーザー エージェントを通して接続するデジタル配信サービスにリンクできます。Chromium の場合、これは Android Play 請求サービス API のウェブ API ラッパーを指します。
この API を使うと、Play ストアのウェブアプリで、デジタル商品の購入をすることができます（Play ポリシーでは、他の方法で支払いを受けることは禁止されています）。これがないと、デジタル商品を販売するウェブサイトを Play ストアからインストールすることはできません。
詳細については、Digital Goods API と Payment Request API で Google Play 請求サービスから支払いを受ける - Chrome Developers をご覧ください。
シグナルが異常終了した場合に、Chrome が AbortSignal オブジェクトの理由をスローするようになります。この便利なメソッドを使うと、シグナル処理関数でシグナルの中断ステータスを確認し、中断の理由を伝播できます。たとえば、シグナルのステータスが変わる可能性がある非同期操作の後に呼び出すことができます。
AbortSignal
多くの場合、中断シグナル処理関数では、シグナルのステータスをチェックし、中断している場合はエラーを伝播する必要があります。この機能により、一貫した便利な方法を使ってそれを実現できるようになります。例は、すでに MDN に掲載されています。
Capability Delegation とは、あるフレームが制限された API を呼び出す機能を放棄し、その機能を信頼する（サブ）フレームに移管できるようにすることを指します。制限された JavaScript（ポップアップ、全画面表示など）を呼び出す機能を既知の信頼するサードパーティ フレームに委譲する必要があるアプリは、この API を使って、指定した期間、その機能を対象のフレームに移管できます。この機能は、iframe の allow 属性のような静的なメカニズムとは対照的です。
多くの販売者のウェブサイトに独自ドメインのオンライン ストアがホストされていますが、カード決済に関するセキュリティや規制に準拠する複雑さに対応するために、支払いの回収や処理インフラストラクチャは決済サービス プロバイダ（PSP）にアウトソースされています。このワークフローは、販売者のウェブサイトのトップ（販売者）フレームに他の部分とうまく調和する「支払い」ボタンを配置し、支払いリクエストのコードは PSP によるクロスオリジン iframe に配置するという形で実装されます。PSP のコードで使われる Payment Request API は、一時的にユーザーがアクティブ化することによって制御されます（悪意のある試みによって、支払いリクエストが自動で実行されたり繰り返されたりすることを防ぐため）。トップ（販売者）フレームのユーザー インタラクションは iframe から見ることができないので、決済処理を始める前に、トップフレームのクリックに応答して PSP コードに委譲する必要があります。
ウェブ デベロッパーは、HIDDevice forget() メソッドを使うことで、ユーザーが許可した HIDDevice へのパーミッションを自発的に取り消すことができます。HID デバイスにアクセスする長期パーミッションを保持する必要がないサイトもあります。たとえば、多くのデバイスがある共用コンピュータで使われる教育用ウェブ アプリケーションでは、ユーザー生成パーミッションが大量に蓄積されると、ユーザー エクスペリエンスの悪化につながります。 この問題を避けるには、最初のリクエストのパーミッションをデフォルトでセッション スコープにしたり、あまり使われないパーミッションに有効期限を設けたりといったユーザー エージェント側の対策と合わせて、サイト自体が不要になったユーザー生成パーミッションをクリーンアップできるようにする必要があります。
HIDDevice
forget()
mix-blend-mode プロパティで "plus-lighter" 値がサポートされます。これにより、ソースカラーとデスティネーション カラーにそれぞれのアルファを掛けたものが加算されます。この操作は、共通のピクセルを含む 2 つの要素をクロスフェードする場合に便利です。この場合に "plus-lighter" を使うと、ある要素の不透明度が 0 から 1 に変わる間に別の要素の不透明度は 1 から 0 に変わるので、共通ピクセルの外観は変化しないことが保証されます。
mix-blend-mode
"plus-lighter"
このヒントには、"WoW64-ness"（64 ビット Windows で実行される 32 ビットアプリ）を使うサイトが User-Agent 文字列を UA-CH に移行する際の下位互換性シムとしての用途しかありません。ブール値を返します。
WritableStream を使う際、すべての書き込み操作が終わるまで待機せずにシリアルポートをクローズできるようになります。ポートがピアデバイスからのフロー制御シグナルを待機している場合、無限にブロックされる可能性があります。WritableStream を中断する目的は、背後にあるシンクへのデータの書き込みを即座に停止することにあります。
WritableStream
wss スキームの WebSocket で、単にデフォルトの "http/1.1" プロトコルをオファーする新しい接続を開始する際に、TLS ALPN 拡張が含まれるようになります。現在のところ、HTTPS 接続とは異なり、この接続は ALPN をオファーしません。この変更により、Firefox と Safari と挙動が一致し、クロスプロトコル攻撃（ALPACA など）に対して強固になり、wss で False Start 最適化を利用できるようになります。また、HTTPS DNS レコードの処理もシンプルになります。
WebSocket
ウェブ デベロッパーが NDEFReader makeReadOnly() メソッドを使うと、Web NFC で NFC タグを永久的に読み取り専用にすることができます。
NDEFReader
makeReadOnly()
WebTransport で serverCertificateHashes オプションを使うと、ウェブ公開鍵基盤（PKI）は使わずに、期待される証明書ハッシュに対して証明書を認証することによって、WebTransport サーバーに接続します。
WebTransport
serverCertificateHashes
ウェブ デベロッパーは、この機能を使うことで、通常は公式に信頼された証明書を取得するのが難しい WebTransport サーバーに接続できます。たとえば、パブリックにルーティングできないホストや、暫定的な用途の仮想マシンなどです。
このバージョンの Chrome でサポートが終了するのは、この記事の最初に記載されている一件のみです。 現在サポートの終了作業が行われている機能と以前に削除された機能のリストは、ChromeStatus.com をご覧ください。
