WebSocketコンストラクタの2番目の引数として、オプションバッグ（WebSocketInit辞書）を渡す機能を追加します。このオプションバッグは、当初は「protocols」オプションをサポートし、開発者がサブプロトコルを指定できるようにします（既存のprotocols引数と同様）。また、将来のオプションの拡張ポイントとしても機能します。

以前は、これはconst socket = new WebSocket("wss://example.com:8080", "soap")と書かれていました。その後は、 const socket = new WebSocket("wss://example.com:8080", { protocols: "soap" })とも書くことができます。

この変更については、 https://github.com/whatwg/websockets/issues/42および仕様に関するプルリクエストhttps://github.com/whatwg/websockets/pull/76を参照してください。

中止理由が指定されている場合は、フェッチプロミスだけでなく、Response オブジェクトとその ReadableStream のメソッドにも中止理由を表示します。これにより、標準規格への準拠におけるギャップが埋められ、開発者が提供する中止理由が意図されたすべての場所で表示されるようになります。

WebSocketコンストラクタにtargetAddressSpaceオプションを渡す機能を追加しました。これにより、開発者は、パブリックホスト名へのWebSocket接続を「ローカル」または「ループバック」宛先として扱うように指定できます。これは、Fetch APIの既存のサポートと一致するものです。主なユースケースは、HTTPSをまだサポートしていないローカルサーバーへの接続時に、混合コンテンツの制限を回避するための回避策を提供することです（ローカルネットワークアクセス権限にはセキュアなコンテキストが必要となるため）。

例：ローカルサーバーに接続する公開サイトは、ホスト名を使用することで、使用する正確なプライベートIPアドレスを手動で設定する必要を回避できます。

const ws = new WebSocket("ws://local-server.example", { targetAddressSpace: "local"}

これにより、WebSocket接続がローカルアドレスへの接続として認識され、セキュアな環境で実行された場合の混合コンテンツブロックが回避されます。WebSocket接続を成功させるには、ユーザーがサイトにローカルネットワークのアクセス許可を与える必要があり、ホスト名はローカルIPアドレスに解決される必要があります（そうでない場合はブロックされます）。

これは、WebSocket コンストラクターにオプションバッグを追加するhttps://chromestatus.com/feature/5080055102439424を基にしています。

Chrome では、安全でない（HTTP）接続にアクセスすると、デフォルトでユーザーにメッセージが表示されるようになりました。IT 管理者は、 HttpsOnlyModeポリシーを使用して、この確実の動作を制御できます。

バックグラウンドフェッチリクエストでまたはローカルループバックサーバーにリクエストを送信する場合、Service Workerのオリジンに正しいローカルネットワークアクセス（LNA）権限があることが必須となりました。

これにより、Chromium の実装がバックグラウンドフェッチ仕様の意図と統合するようになります。 バックグラウンドフェッチ仕様では、ただしリクエストはフェッチ仕様を経由し、同じセキュリティポリシー（この場合は LNA チェック）が適用されると定められています。

企業においては、Service Worker からの通常の Fetch API リクエストに対して従来行っていたのと同様の方法で、既存の LNA エンタープライズ ポリシーを使用できます。

• ローカルネットワークアクセス制限の一時的なオプトアウト
• LocalNetworkAccessAllowedForUrls
• LoopbackNetworkAllowedForUrls
• LocalNetworkAccessPermissionsPolicyDefaultEnabled
• ローカルネットワークアクセスIPアドレススペースオーバーライド

scroll-marker-group プロパティが拡張され、以下のモードがサポートされるようになりました。

1. 'links' - 生成される::scroll-marker-groupは「links」モードで動作し、ナビゲーションリストのように機能します。省略した場合、これがデフォルトモードとなります。
2. 'tabs' - 生成された ::scroll-marker-group は「tabs」モードで動作し、タブリストのように機能します。

各モードでは、WAI-ARIA パターンに従って、::scroll-marker-group および ::scroll-markers のフォーカス順序とアクセシビリティ動作が変更されます。

詳細はこちら：

リンクモード（デフォルト）

このモードは、標準的なナビゲーションランドマークとフラグメントアンカーを組み合わせたものを模倣するように設計されています。

意味役割

::scroll-marker-group はナビゲーションの役割を担い、::scroll-marker 要素はリンクの役割を担います。これは、<nav> + <a> という構造パターンに完全に対応しています。

キーボードナビゲーション

すべての ::scroll-marker 要素は連続したタブストップであり、標準のアンカーリンクのリストのように機能します。

影響を受けない標的

元の要素は特定の役割に強制されることはなく、文書の自然な意味構造はそのまま維持される。

活性化フォーカス管理

リンクマーカーがアクティブになると、シーケンシャルフォーカスナビゲーションの開始点がターゲット要素（元の要素）に設定され、マーカーからフォーカスが失われます。これは、標準的な内部リンクである<a href="#target">をクリックしたときのネイティブな動作を模倣しています。

タブモード

このモードは、タブパターンをネイティブに再現するように設計されており、タブ付きカルーセルパターンのインタラクティブな基盤として機能します。

意味役割

::scroll-marker-group には暗黙的に tablist ロールが割り当てられ、::scroll-marker 要素は tab ロールとして機能し、それらの元となる要素には tabpanel ロールが割り当てられます。これは、必要な WAI-ARIA タブ構造を反映しています。

キーボードナビゲーション（ロービングタブインデックス）

これは、標準的な手順で説明されている複雑なキーボード操作に準拠しています。アクティブな::scroll-markerのみがタブストップとして機能します。ユーザーは矢印キーを使用してフォーカスグループ内を移動（マーカー間を切り替え）するため、20個のカルーセルドットをタブキーで移動しなければならない「タブトラップ」を回避できます。

焦点範囲管理

マーカーはフォーカスナビゲーションスコープの所有者として機能します。アクティブなマーカーからTabキーを押すと、フォーカスがアクティブなタブパネルの内容に直接移動し、タブインターフェースの仕様に準拠します。

木の剪定

非アクティブなタブのコンテンツは、アクセシビリティツリーから明示的に非表示になります。これは、非アクティブなタブパネルにおける aria-hidden="true" または inert の期待される動作を模倣しており、開発者が状態変更を手動でスクリプト化する手間を省きます。

活性化の焦点

マーカーがアクティブになると、フォーカスはマーカーに保持されます。これは、標準的なタブの動作とまったく同じです。

FontFace の width 属性と @font-face font-width 記述子を stretch および font-stretch のエイリアスとして公開します。Chromium を更新された CSS Font Loading および CSS Fonts 4 仕様に準拠させます。開発者は、FontFace.width および CSS font-width を使用して、stretch および font-stretch と互換的にフォント フェイスの幅を検査または初期化できるようになりました。

CSS Typed OM 仕様では、CSSStyleValue 階層をワーカーのグローバルスコープ ([Exposed=(Window, Worker, PaintWorklet, LayoutWorklet)]) に公開していますが、Blink では CSSStyleValue、CSSKeywordValue、CSSNumericValue、CSSUnitValue、CSSUnparsedValue のみが Window とワークレットに公開されていました。そのため、Firefox や Safari とは異なり、これらのコンストラクタはワーカーでは未定義でした。

サイトがiframeのレスポンシブサイズ調整（親ドキュメント内の<iframe>要素のサイズをiframeドキュメントのレイアウトオーバーフローサイズに合わせることで、子ドキュメントでのスクロールを回避する）を有効/無効にできるようにする。

セキュア決済確認のlocaleデータフィールドを更新し、指定された言語タグのいずれもセキュア決済確認ダイアログで使用される言語と一致しない場合、サポートされていないDOMExceptionを返すようにします。フィールドが設定されていないか空の場合は、この検証はスキップされます。

これは、Web開発者がセキュア決済確認に提供するデータの言語とダイアログの言語を一致させるのに役立ちます。

TC39 の提案でArray.prototype.includes開発者がイテレータが特定の値を返すかどうかを問い合わせることができるようにするものです。Array.prototype.includes に類似しています。

ポップオーバーとダイアログのライトディスクラム動作を改善および簡素化し、いくつかのバグを修正しました。「ライトディスクラム」とは、ポップオーバーまたはダイアログの外側をクリックすると閉じる動作のことです。修正されたバグには、タッチスクリーンでのスクロールジェスチャーでライトディスクラムがトリガーされなくなったこと、および右クリックでライトディスクラムがトリガーされなくなったことが含まれます。

この変更の根本的な仕組みは、ブラウザがポインターダウンイベントとポインターアップイベントの組み合わせではなく、クリックイベントを使用してライトの削除をトリガーするようになるという点です。

Window Shape API を使用すると、ChromeOS で許可リストに登録された独立したウェブアプリのウィンドウ形状をカスタマイズできます。デベロッパーは非四角形や非連続のウィンドウレイアウトを有効にすることで、ネイティブアプリのデザインに合わせた独自のユーザーエクスペリエンス（ウィジェット、フローティングパネル、オーバーレイなど）を実装できます。 window.setShape API を使用するには、ウィンドウが「フレームなし」の表示モードになっていて、ウィンドウ管理の権限が付与されている必要があります。

管理者は、ウィンドウ管理に関するポリシーを使用してこの機能を管理できます。

• DefaultWindowManagementSettingでは、すべてのアプリのウィンドウ管理のデフォルトの状態を設定します。以下のポリシーでこのデフォルト設定をオーバーライドできます。
• WindowManagementAllowedForUrls では、指定したオリジンの独立したウェブアプリがユーザーの操作なしでフレームなしモードに移行し、カスタムのウィンドウ形状を設定することを許可します。
• WindowManagementBlockedForUrlsでは、指定したオリジンに対して権限をブロックし、Chrome にカスタムのウィンドウ形状を削除させ、他の利用可能な表示モードにフォールバックさせます。

ウェブ全体で自動化されたトラフィックが増加しており、多くのウェブサイトは、不要なトラフィックに対抗するために、CAPTCHAなどの認証方法を導入するなど、ユーザーの利用を阻害する手段を増やしている。これはすべてのユーザーのウェブ利用体験を低下させるが、特にプライベートブラウジングモードのユーザーへの影響は大きい。

プライベート検証トークン（PVT）は、エントロピーの低い仕組みであり、ウェブサイトがユーザーが通常のブラウジングで築いた信頼をプライベートブラウジングモードに移行させることで、ユーザーのストレスを軽減します。PVTは通常のブラウジングセッション中に発行され、プライベートブラウジングモードで使用されます。