特に記載のない限り、下記の変更は Android、ChromeOS、Linux、macOS、Windows 向けの最新の Chrome ベータ版チャンネル リリースに適用されます。ここに記載されている機能の詳細については、リンクまたは ChromeStatus.com の一覧でご確認ください。2022 年 9 月 29 日の時点で Chrome 107 はベータ版です。PC 向けの最新版は Google.com で、Android では Google Play ストアでダウンロードできます。
# CSS grid-template プロパティ補間
CSS グリッドの grid-template-columns プロパティと grid-template-rows プロパティを使うと、行の名前を定義してグリッドの列と行のサイズを追跡できます。Microsoft の貢献者の皆様のおかげで、上記のプロパティで補間がサポートされました。グリッドのレイアウトが複数の状態間をスムーズに遷移できるようになり、アニメーションや遷移が途中で中断することはなくなります。
# プライバシー保護に対応した画面共有制御
Screen Capture API で既存の Media Capture と Streams API に追加機能が導入され、ユーザーが画面やその一部（ウィンドウなど）を選択してメディア ストリームとしてキャプチャできるようになります。このストリームは、記録したり、ネットワークを経由してほかのユーザーと共有したりできます。今回のベータ版では、この API にいくつかの新機能が追加されます。
ヒントを使うと、getDisplayMedia() を呼び出す際に、ウェブ アプリケーションがユーザーに提示するタブの一覧から現在のタブを除外するかどうかをブラウザに指示できます。
これにより、ユーザーがアプリを実行しているタブを意図せずに選択し、自分自身がキャプチャされることを防ぎます。そのため、映像がループする現象が起きて、ユーザーが混乱したり、リモートユーザーとの議論が中断されたりすることはなくなります。
Chrome で画面共有をしているときに、タブ切り替えボタンを表示するかどうかをプログラムで制御するオプションを追加します。このオプションは、navigator.mediaDevices.getDisplayMedia() に渡します。
[Share this tab instead] ボタンを使うと、ユーザーは共有するタブをシームレスに切り替えることができます。ビデオ会議タブを再選択し、ボタンをクリックして再度 getDisplayMedia() を開始したり、多くのタブが表示される一覧から新しいタブを選択したりする必要はありません。すべてのウェブ アプリケーションがこの動作に対応しているわけではないので、この動作は条件に応じて公開されます。
getDisplayMedia() を呼び出すと、ブラウザでタブ、ウィンドウ、モニターといったディスプレイ サーフェスを選択する画面がユーザーに提示されます。displaySurface 定数を使ってウェブ アプリケーションからブラウザにヒントを与えると、特定の種類のサーフェスを優先的に提示できます。
以上の機能は、意図しない画面共有を防ぐうえで役立ちます。詳しくはこちらで説明しています。
# Resource Timing のレンダリング ブロック状態
PerfomanceResourceTiming に、リソースのレンダリングのブロック状態を示すフィールドを追加します。現在、デベロッパーが実際にレンダリングのブロックが起きているリソースを知りたい場合、複雑な経験則を使用するしかありません。この新しいフィールドから、これを直接把握できるようになります。
# 権限ポリシー オリジンのワイルドカード
この機能により、権限ポリシーでワイルドカードがサポートされます。たとえば、SCHEME://*.HOST:PORT（https://*.foo.com/ など）のような構造です。この場合、有効なオリジンは SCHEME://HOST:PORT（https://foo.com/など）から構築されます。HOST は少なくとも eTLD+1（登録可能なドメイン）である必要があります。つまり、https://*.bar.foo.com/ は指定できますが、https://*.com/ は指定できません。スキーム部とポート部のワイルドカード指定はサポートされません。また、https://*.foo.com/ には https://foo.com/ は含まれません。これまで、権限ポリシーは次のようになっている必要がありました。
permissions-policy: ch-ua-platform-version=(self "https://foo.com" "https://cdn1.foo.com" "https://cdn2.foo.com")
この機能が導入されたことで、次のようにすることができます。
permissions-policy: ch-ua-platform-version=(self "https://foo.com" "https://*.foo.com")
この機能はフォーム要素に rel 属性を追加します。これにより、rel=noopener が指定されているフォーム要素から開くウェブサイトで window.opener が利用できなくなります。また、rel=noreferrer を使ってリファラー ヘッダーが送られることを防ぐこともできます。
# オリジン トライアル
今回のリリースの Chrome には、2 つの新しいオリジン トライアルが含まれています。
# Declarative PendingBeacon API
これはステートフル ビーコン API の 1 つで、ビーコンの送信タイミングをブラウザで制御できるようにします。 ビーコン とは、特定のレスポンスを求めずにバックエンド サーバーに送信するデータの集まりを指します。ユーザーがページを訪問し終わった後にこのデータを送信したいというニーズは多いものの、"send" 呼び出しをする適切なタイミングがありません。この API は、送信処理をブラウザ自身に委譲するので、ページがアンロードされたときやページが非表示になったときのビーコンをサポートでき、デベロッパーがそのタイミングで送信処理を実装する必要はなくなります。
このトライアルは、Chrome 109 まで行われる予定です。トライアルへの登録はこちらから行うことができます。
# Permissions-Policy: unload
この機能を使うと、ページで unload イベント ハンドラが実行できなくなります。この機能の目的は、すべての unload ハンドラを削除したサイトで、意図しないハンドラが新しく追加されないようにすることです。この機能はサイトを unload イベント ハンドラを使わないように移行する際に活用でき、BFCache のヒット率改善につながります。
このトライアルは、Chrome 109 まで行われる予定です。トライアルへの登録はこちらから行うことができます。
# サポートの終了と機能の削除
このバージョンの Chrome では、以下のサポートの終了と機能の削除が行われます。サポートの終了が予定されている機能、現在サポートが終了している機能、以前に削除された機能のリストは、ChromeStatus.com をご覧ください。
今回の Chrome のリリースでは、1 つの機能のサポートが終了します。
# Expect-CT
Expect-CT HTTP ヘッダーは、デフォルトで Certificate Transparency が必須化される前に、ウェブサイトがこれをオプトインできるようにします。また、報告機能も提供されるので、デベロッパーが CT の設定ミスを見つけるうえでも役立ちます。
Expect-CT HTTP ヘッダーは、Certificate Transparency（CT）の必須化に向けた移行に役立つように設計されました。具体的には、すべての公開ウェブサイトで CT が必須化される（Chrome により）前に、高価値なウェブサイトが CT の必須化をオプトインしたり、高いセキュリティに対応していることを報告したりできるようにするものでした。ただし、Expect-CT はすでに存在意義を失っています。現在の Chrome では、すべての公開サイトで CT が必須になっているので、すでに Expect-CT は必要ありません。Expect-CT は他のブラウザでも実装されていないので、これを削除しても互換性の問題は発生しません。
