安定版のリリース予定日: 2026年10月20日
現在、Web開発者はモジュールの読み込み失敗を再試行することができません。これは、失敗がキャッシュされてしまうため、再試行してもすぐに失敗するからです。今回のモジュール読み込み動作の変更により、失敗したモジュールの読み込みを手動で再試行できるようになります（例えば、 import()再度呼び出すなど）。これにより、不安定なネットワーク上でモジュールを使用する際に開発者（およびユーザー）が抱える大きな問題を解決できます。
rel=compression-dictionaryリンクを取得する場合：
WebTransportOptions を介してカスタム HTTP リクエスト ヘッダーを渡す機能と、WebTransport インスタンスを介してサーバー応答ヘッダーを検査する機能を追加しました。これにより、Web アプリケーションは最初の CONNECT ハンドシェイク中にメタデータ、認証トークン、カスタム パラメータを提供し、接続が確立された後にサーバーから提供されるヘッダーにアクセスできるようになります。
ナビゲーションを開始した要素（リンク、ボタン、フォームなど）を選択します。選択された要素は、ナビゲーション全体を通して選択された状態になります。
random() 関数は、CSS に生成的な乱数性をもたらし、Web 制作者が指定された範囲内で乱数を生成することを可能にします。
例えば、Web制作者はrandom()関数を使って、コンテナ内に要素をランダムに配置することができます。 .dot { /* 各ドットをランダムに配置する */ position: absolute; top: random(0%, 100%); left: random(0%, 100%); }
この機能にはキャッシュ制御も含まれています。デフォルトでは、各 random() 関数は新しい一意の値に解決されます。Web 作成者は、関数の最初の引数として <random-key> 値を渡すことで、プロパティや要素間でランダムな値がどのように共有されるかを制御できます。
overflowプロパティを拡張し、 clipと組み合わせたスクロール可能な値をサポートします (例: overflow: scroll clip )。これにより、 position: sticky軸ごとに異なる親スクロールコンテナで制限できるようになり、 overflow: clip使用する軸が所定の位置に留まるようにする方法が作成者に提供されます。
https://github.com/w3c/csswg-drafts/issues/9519
scroll-snap-typeに「pair」キーワードを追加します。このキーワードを使用すると、コンテナのスクロールが一方の軸上の要素にスナップした場合、もう一方の軸上の同じ要素にもスナップするようになります。既存の仕様では、「both」キーワードにより、スクロールコンテナがX軸とY軸でスナップ対象を個別に選択し、異なる対象にスナップすることが可能になっています。
ChromiumのIndexedDBの実装は、LevelDBとフラットファイルを組み合わせた従来の実装に代わり、SQLiteをベースに書き直されました。Web APIに変更はありません。
これにより、信頼性が向上し、性能も多少向上すると予想される。
現時点では、これは新しいデータストアに適用されます。これは複数段階にわたるロールアウトのステップ2です。ステップ1（インメモリ、つまりシークレットコンテキストへのロールアウト）については、 https://chromestatus.com/feature/5126896685809664を参照してください。ステップ3では、LevelDBストアからSQLiteストアへの既存データの移行を行います。
このステップでは、ユーザーが初めてサイトにアクセスしたとき、またはサイトデータをクリアした後に、新しいIDBデータがSQLiteを使用するバックエンドに保存されますが、LevelDBに保存されている既存のデータには影響はありません。
注意すべき相違点の一覧については、下記のドキュメントリンクを参照してください。
WGSL の@builtin(frag_depth)にlessまたはgreater修飾子を指定する機能を追加します。
現在の@builtin(frag_depth)描画呼び出し時に早期Z最適化を無効にするため、パフォーマンスの低下を招く可能性があります。新しい修飾子を使用すると、バッファモードを明示的に設定でき、早期Z最適化を適用できるようになります。
ウェブ異常通信（ WebRTC ）の Diagnostic Logging API を使用すると、承認されたウェブ アプリケーションが WebRTC 診断データの収集をトリガーして、ローカル デバッグに使用できるようになります。また、ユーザーの承認を得た範囲、ユーザーエージェントのバグ修正や改善に必要な情報を提供する目的で、アプリケーションが WebRTC 診断データをユーザー エージェントと共有することも可能になります。
管理者は、エンタープライズ ポリシーWebRtcDiagnosticLogCollectionAllowedForOriginsを使用して診断ログを有効にできます。
フェンスフレームとは、ページにコンテンツを埋め込む際に、フェンスフレームとその埋め込み元との間でデータを共有する機能を持たない、ネストされたフレームのことです。
window.fence API には、保護されたオーディエンスと SelectURL を使用して作成された FF からのプライバシーに配慮した広告レポート用に作成されたフェンスフレーム広告レポート (FFAR) JS API と、PA コンポーネント広告をサポートする getNestedConfigs() が含まれています。
この目的は、これら両方を除去することです。フェンスフレーム要素の除去は、以下に詳述する2段階で行われます。
PA と selectURL の削除 (またはスタブ API の置き換え) により、FF はナビゲートできなくなり、削除しても安全です。フェンス付きフレームは、FencedFrameConfig[1] の urn:uuid を使用してのみナビゲートできます。FencedFrameConfig[1] は、runAdAuction と selectURL の戻り値を使用してのみ作成できます。これらの API は、次の Intent スレッドに従って、M152 で非推奨となり削除されます: Protected Audience[2]、Shared Storage[3]。
計画：フェンスで囲まれたフレーム要素がもはやナビゲートできないことを踏まえ、以下の段階でコードからその要素を削除することを提案します。
M156: フェンス付きフレーム要素とその関連する IDL 依存関係をスタブとして保持します。これは、fenced-frame-element.config.setSharedStorageContext() などの JavaScript 呼び出しで例外が発生しないようにするためです。
M156: 同じマイルストーンで、window.fence API も完全にスタブ化します。FF のドキュメントナビゲーションがないため、これらの API は呼び出すことができなくなり、何も動作しなくなります。
M157 カナリア/ベータ版: フィールドトライアルを通じて、スタブFF HTML要素の削除を段階的に展開します。なお、この要素を削除すると、HTMLUnknownElementに解決されます。
現時点では、上記すべての手順について承認を求めています。
[1] https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/html/fenced_frame/fenced_frame_config.idl [2] https://groups.google.com/a/chromium.org/g/blink-dev/c/k_nubsMb97g/m/awPD4IGLBAAJ [3] https://groups.google.com/a/chromium.org/g/blink-dev/c/uh5Ke6qyegc/m/WFTFnhyJBAAJ