この記事は Chromium Blog の記事 "Chrome 80, Content Indexing, ES Modules and More" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

特に記載のない限り、下記の変更は Android、Chrome OS、Linux、macOS、Windows 向けの最新の Chrome ベータ版チャンネル リリースに適用されます。ここに記載されている機能の詳細については、リンクまたは ChromeStatus.com の一覧でご確認ください。2019 年 12 月 19 日の時点で Chrome 80 はベータ版です。

Content Indexing


プログレッシブ ウェブアプリは、Cache Storage API や IndexedDB を使って、イメージ、動画、記事などのコンテンツをオフライン アクセス用に保存できます。しかし、ユーザーはどのようにしてこのコンテンツを見つけるのでしょうか。ネットワークが利用できなくてもコンテンツを参照したり使用したりできることを、どうやって知るのでしょうか。

Content Indexing API は、ウェブアプリがすでにキャッシュしているコンテンツのメタデータを提供します。具体的には、保存されたメディアを表示する HTML ドキュメントの URL を保存します。この新しい API を使えば、リソースの追加、一覧表示、削除ができます。ブラウザはインデックス内にあるこの情報を使い、オフライン対応コンテンツのリストを表示できます。Chrome 80 では、そのリストはこのように表示されます。

Content Indexing API は、Chrome 80 から Chrome 82 までのオリジン トライアルです。API の詳細については、Content Indexing API を使用した実験をご覧ください。登録に関する情報や、本リリースで開始された他のオリジン トライアルのリストについては、オリジン トライアルのセクションをご覧ください。

Web Worker の ECMAScript Module

Web Worker は、大半のブラウザで 10 年以上前から利用できます。その結果、モジュールをワーカーにインポートする方法である importScripts() は、もはや最新技術とは見なされなくなっています。この機能は、インポートするスクリプトを取得して評価する間、ワーカーの実行をブロックします。さらに、スクリプトをグローバル スコープで実行するので、名前の衝突やそれに関連する問題を引き起こす可能性があります。

そこで導入されるのが Module Worker です。Worker のコンストラクタは、type オプションで値 "module" をサポートするようになります。これにより、スクリプトの読み込みと実行が <script type="module"> と同じ動作になります。 


const worker = new Worker('worker.js', {
  type: 'module'
});

Module Worker は、標準の JavaScript のインポートと遅延読み込み用のダイナミック インポートをサポートしており、ワーカーの実行をブロックしません。背景や詳細については、Web Worker の ES Module をご覧ください。

オリジン トライアル

このバージョンの Chrome には、以下のオリジン トライアルが導入されています。オリジン トライアルとして新機能を試せるようにすることで、ウェブ標準コミュニティにユーザビリティ、実用性、有効性についてのフィードバックを提供することができます。以下の項目を含め、現在 Chrome でサポートされているオリジン トライアルに登録するには、オリジントライアル ダッシュボードをご覧ください。オリジン トライアル自体の詳細については、ウェブ デベロッパーのためのオリジントライアル ガイドをご覧ください。

Contact Picker の新しいプロパティ

このバージョンの Chrome には、Contact Picker API が搭載されています。Chrome 77 で開始されたオリジン トライアルは終了となります（詳細は後述）。同時に、この API に機能を追加した新しいオリジン トライアルが開始されます。ユーザーに連絡先の選択をリクエストする前に、アプリはどのデータを返してもらいたいかを指定しなければなりません。現時点で利用できるのは、連絡先の名前、メールアドレス、電話番号のみとなります。新しいオリジン トライアルでは、これにユーザーの郵送先住所（'address'）とイメージ（'icon'）が加わります。

今回のリリースに追加されたその他の機能

Mixed Contents の自動アップグレード

現在の Chrome は、HTTPS サイト内の HTTP コンテンツを自動アップグレードしています。これは、安全なコンテンツを利用できない場合に、HTTP にフォールバックせずに URL を HTTPS に書き換えることによって実現しています。このバージョンの Chrome では、オーディオと動画のコンテンツのみがそのように扱われています。

Compression Streams

JavaScript で、ストリームを使って gzip や deflate 圧縮を実行できるようになります。対応しているのは、CompressionStream と DecompressionStream の 2 つのインターフェースです。

この機能を使わずにストリーム データを圧縮することも可能ですが、zlib などの一般的なライブラリは複雑で使いづらいものです。デベロッパーは Compression Streams を使って簡単にデータを圧縮できるので、アプリケーションに圧縮ツールをバンドルする必要はなくなります。

Contact Picker API

Contact Picker API は、Android Chrome 用の新しいオンデマンド ピッカーです。これを使うと、ユーザーは連絡先リストのエントリを選択し、その詳細情報の一部をウェブサイトと共有できます。ユーザーは、共有したいときに共有したい情報のみを共有し、友だちや家族と簡単につながることができるようになります。詳細については、ウェブ用の連絡先ピッカーをご覧ください。さらに、新しいオリジン トライアルでは、ContactsManager.getProperties() で返されるプロパティが追加されています。詳細については、上記のオリジン トライアルのセクションをご覧ください。

Cookie のアップデート

Chrome 51 と Firefox 60 に SameSite 属性が導入され、Cookie を同一サイト（ファースト パーティとも呼ばれます）のコンテキストに制限するかどうかをサイト側で宣言できるようになります。これにより、クロスサイトリクエスト フォージェリ（CSRF）のリスクを低減できます。

Chrome 80 では、以下に記述する下位互換動作が削除されます。この機能の詳細については、SameSite Cookie の説明をご覧ください。

SameSite 属性のデフォルト 'None' の禁止

SameSite 属性のデフォルトは Lax になります。これは、トップレベルのナビゲーションをする場合のみ、他のサイトで Cookie が利用できることを意味します。Chrome で当初実装されていたように、SameSite 属性のデフォルトは None であり、これが実質的にウェブの現状でした。Cookie には有効なクロスサイト ユースケースがありますが、サイト所有者がクロスサイト Cookie の使用を許可したくない場合に、その意図を宣言したり強制したりする方法はありませんでした。

安全でないコンテキストでの値 'None' の禁止

SameSite 属性が None に設定された場合、Chrome は Secure 属性の存在も要求するようになります。Secure 属性は、追加される Cookie を HTTPS などの安全なプロトコル経由でのみ送信することを求めます。

CSS の改善

line-break: anywhere

line-break: anywhere 宣言をすると、すべての印字文字単位にソフトラップが適用されるようになります。これには、句読点文字や保持されるスペース、単語の中なども含まれます。この宣言をすると、GL、WJ、ZWJ 文字クラス（UAX 14 を参照）による文字や word-break プロパティによる強制を含め、改行に関するすべての禁止事項は無視されます。

overflow-wrap: anywhere

overflow-wrap: anywhere 宣言を使うと、行内に他の受け入れ可能な改行ポイントがない場合に、そのままでは改行されない文字列を任意の場所で改行することができます。さらに、min-content 固有サイズを計算する際には、anywhere によって生じるソフトラップ適用の可能性も考慮されます。

暗号化されたメディアのデコード

暗号化されたメディアで MediaCapabilities.decodingInfo()  の機能を利用できるようになります。decodingInfo() メソッド（複数のブラウザで利用可能）を使うと、ウェブサイトがクライアントのデコード機能に関する追加情報を得られます。これにより、ユーザーが詳しい情報に基づいてメディア ストリームを選択できるようになり、利用可能な帯域幅や画面サイズに基づいてスムーズかつ電力効率よく動画をデコードするなどのシナリオを実現できます。

Web Payments での配送先住所と連絡先情報の委譲

Payment Handler API で、ブラウザが配送先住所と支払者の連絡先情報の扱いを支払いハンドラに委譲できるようになります。支払いアプリはブラウザよりも正確な情報を保持している可能性があるので、配送先住所と連絡先情報の収集を支払いハンドラに委譲すると、ユーザー エクスペリエンスの向上につながる場合があります。また、ブラウザは、最初に支払いシート UI を表示して配送先住所や支払者の連絡先情報を収集することなく、支払いハンドラのウィンドウを直接表示できるので、チェックアウト手順を 1 段階少なくすることができます。Chrome でのその他の Payment Request API / Payment Handler API の技術的なアップデートについて最新情報を得るには、paymentrequest@chromium.org に参加してください。

Fetch Metadata の宛先ヘッダー

Chrome は Sec-Fetch-Dest HTTP リクエスト ヘッダーをサポートします。このヘッダーは、リクエストの宛先をサーバーに公開し、サーバーがセキュリティ上の判断をする際に参考となる情報を提供します。仕様には、設定可能な値のリストが記載されています。

HTMLVideoElement.getVideoPlaybackQuality()

このメソッドは、動画再生パフォーマンスに関する情報を取得します。このような情報を使用して、ビットレート、フレームレート、または解像度を変更し（上げるまたは下げる）、ユーザー エクスペリエンスを向上できます。

画面外描画キャンバスが getTransform() をサポート

OffscreenCanvasRenderingContext2D が getTransform() をサポートするようになります。CanvasRenderingContext2D のメソッドと同じように、このメソッドから現在コンテキストに適用されている変換行列を取得できます。

SVG ファビコンのサポート

Chrome で、SVG イメージをファビコンに使用できるようになります。拡大可能な形式をファビコンに使用できるため、ウェブサイトやアプリのリソースを削減できます。たとえば、手動で調整した 1 つ（または複数）の小さいサイズのアイコンをウェブサイトに配置し、拡大可能なアイコンを使ってすべてに対応できます。

テキスト URL フラグメント

ユーザーや作成者は、URL で提供されるテキスト フラグメントを利用してページの特定の部分にリンクできるようになります。ページが読み込まれると、ブラウザは対象のテキストをハイライト表示し、フラグメントが表示されるようにスクロールします。たとえば次の URL は、「猫」の Wiki ページを読み込み、text パラメータに記載されているコンテンツにスクロールします。


https://en.example.org/wiki/Cat#:~:text=On islands, birds can contribute as much as 60% of a cat's diet

サポートの終了と機能の削除

このバージョンの Chrome では、以下のサポートの終了や機能の削除が行われます。現在サポートが終了している機能や以前に削除された機能のリストは、ChromeStatus.com をご覧ください。ここに記載されているのは、非推奨化や削除される機能の概要のみです。これらすべての項目の詳細、代替機能、修正点については、Chrome 80 でのサポートの終了と機能の削除を参照してください。

ページ アンロード中のポップアップの禁止

window.open() メソッドを使ってアンロード時に新しいページを開くことができなくなります。ポップアップ ブロッカーはすでにこれを禁止していますが、ポップアップ ブロッカーが有効になっているかどうかにかかわらず、禁止されるようになります。現在のところ、企業は AllowPopupsDuringPageUnload ポリシーフラグを使ってアンロード中のポップアップをブロック解除することができます。このフラグは、Chrome バージョン 82 で削除される予定です。

ページを閉じる際の同期 XMLHttpRequest() の禁止

ユーザーがページを移動するまたは閉じることによってページを離れる際に、同期 XMLHttpRequest() の呼び出しが許可されなくなります。これは、beforeunload、unload、pagehide、visibilitychange に適用されます。

Chrome でページがアンロードされるタイミングで確実にサーバーにデータを送信するには、sendBeacon() または Fetch keep-alive を使うことを推奨します。現在のところ、企業ユーザーは AllowSyncXHRInPageDismissal ポリシーフラグを使ってページ アンロード時の同期 XMLHttpRequest() リクエストを許可できます。デベロッパーは、オリジントライアル フラグ allow-sync-xhr-in-page-dismissal を使って同じことができます。これは、一時的なオプトアウトによる対策です。このフラグは、Chrome バージョン 82 で削除される予定です。

この点の詳細や代替機能については、ページを離れる際の同期 XMLHttpRequest() を改善するをご覧ください。

FTP サポートの非推奨化

Chrome バージョン 72 より、FTP サポート機能の削除が進められています。その理由は、ブラウザからの FTP の利用率はかなり低く、既存の FTP クライアント機能の改善に注力できないためです。また、影響するすべてのプラットフォームで、機能の豊富な FTP クライアントが利用できます。Chrome 80 では、暗号化されていない接続を使用するクライアント機能は、ディレクトリの一覧表示またはリソースのダウンロードに制限されます。詳しくは、Chrome 80 でのサポートの終了と機能の削除をご覧ください。

オリジンクリーンでない ImageBitmap のシリアル化や転送の削除

Chrome 80 以降では、スクリプトからオリジンクリーンでない ImageBitmap オブジェクトのシリアル化または転送を試みると、エラーが発生します。オリジンクリーンでない ImageBitmap とは、CORS ロジックで検証されないクロスオリジン イメージからのデータを含むものです。

プロトコル ハンドリングで安全なコンテキストが必須化

registerProtocolHandler() メソッドと unregisterProtocolHandler() メソッドで、安全なコンテキストが必須となります。これらのメソッドを使うと、クライアントの状態を再構成し、機密データのネットワーク転送を許可できます。

任意の要素に対する -webkit-appearance:button の削除

-webkit-appearance:button が変更され、<button> ボタンと <input> ボタンのみに影響するようになります。button がサポート対象外の要素に指定された場合、その要素はデフォルトの外見となります。その他すべての -webkit-appearance キーワードには、すでにこの制限が課せられています。

Web Components v0 の削除

Web Components v0 が Chrome から削除されます。Web Components v1 API は、Chrome、Safari、Firefox、（間もなく）Edge に搭載されているウェブ プラットフォーム標準です。アップグレードに関するガイダンスは、Web Components のアップデート : v1 API へのアップグレードの猶予期間をご覧ください。今回のサポートの終了は、以下の項目が対象です。
  • Custom Elements v0
  • HTML Imports v0
  • Shadow DOM v0

Reviewed by Eiji Kitamura - Developer Relations Team