Chrome 60 でのサポートの終了と削除

ジョー・メドレー
Joe Medley

Chrome のほぼすべてのバージョンで、プロダクト、パフォーマンス、ウェブ プラットフォームの機能に関して、多数の更新と改善が行われています。この記事では、Chrome 60(6 月 8 日時点でベータ版)のサポート終了と削除について説明します。このリストは随時変更される可能性があります。

セキュリティ

crypto.subtle に安全なオリジンが必要

Chrome 37 以降でサポートされていた Web Crypto API は、常にセキュアでないオリジンで機能してきました。高度な機能に対して安全なオリジンを優先的に選択するという Chrome の長年のポリシーにより、crypto.subtle は安全なオリジンでのみ表示されます。

削除の目的 | Chromium のバグ

コンテンツから開始されたデータ URL へのトップフレーム ナビゲーションを削除する

技術的な知識のないブラウザ ユーザーにはなじみが薄いため、なりすましやフィッシング攻撃で data: スキームが使用されるようになっています。これを防ぐため、ウェブページが先頭のフレームで data: URL を読み込まないようにブロックしています。これは、<a> タグ、window.openwindow.location などのメカニズムに適用されます。data: スキームは、ページで読み込まれたリソースに対して引き続き機能します。

この機能は Chrome 58 でサポートが終了し、削除されました。

削除の目的 | Chromestatus Tracker | Chromium のバグ

一部の blob に対して navigator.sendBeacon() を一時的に無効にする

navigator.sendBeacon() 関数は、Chrome 39 以降で使用できます。元の実装では、関数の data 引数には、型が CORS セーフリストに登録されていない任意の blob を含めることができました。Google は、これは潜在的なセキュリティ上の脅威であると考えていますが、まだ悪用を試みた人はまだいません。この問題に対する合理的な即時修正がないため、一時的に、型が CORS セーフリストに登録されていない blob では sendBeacon() を呼び出せなくなっています。

この変更は Chrome 60 で実装されましたが、Chrome 59 に統合されています。

Chromium のバグ

CSS

シャドウ ピアスの子孫コンビネータを子孫コンビネータのように動作させる

CSS スコーピング モジュール レベル 1 の一部であるシャドウ ピアス子孫コンビネータ(>>>)は、特定の祖先要素の子がシャドウツリー内に現れる場合でも、それに一致することを意図していました。これにはいくつかの制限がありました。まず、仕様上、この関数を使用できるのは querySelector() などの JavaScript 呼び出しでのみ使用でき、スタイルシートでは機能しません。さらに重要なことに、ブラウザ ベンダーは Shadow DOM の 1 レベルを超えて機能させることができませんでした。

そのため、Shadow DOM v1 などの関連仕様では、子孫コンビネータが削除されました。Chromium からこのセレクタを削除してウェブページを壊すのではなく、シャドウ ピアスの子孫コンビネータのエイリアスを子孫コンビネータに付けることにしました。元の動作は Chrome 45 でサポートが終了しました。新しい動作は Chrome 61 に実装されています。

削除の目的 | Chromestatus Tracker | Chromium のバグ

JavaScript

RTCPeerConnection.getStreamById() のサポート終了と削除

2 年ほど前に、getStreamById()WebRTC 仕様から削除されました。他のほとんどのブラウザでは、すでに実装から削除されています。この関数はほとんど使われていないと考えられていますが、getStreamById() が引き続きサポートされている Safari 以外の Edge および WebKit ベースのブラウザには、相互運用性に関する軽微なリスクがあると考えられています。代替の実装を必要とするデベロッパーは、下記の「削除するインテント」でサンプルコードをご覧ください。

削除は Chrome 62 で行われます。

削除の目的 | Chromestatus Tracker | Chromium のバグ

SVGPathElement.getPathSegAtLength のサポート終了

2 年以上前に、getPathSegAtLength()SVG 仕様から削除されました。httparchive でこのメソッドのヒット数がわずかなため、Chrome 60 でサポートが終了します。削除は Chrome 62 で行われ、10 月上旬または中旬にリリースされる予定です。

サポート終了の予告 | Chromestatus Tracker | Chromium のバグ

getContextAttributes() をフラグの背後に移動する

getContextAttributes() 関数は、2013 年から CanvasRenderingContext2D でサポートされています。ただし、この機能はどの標準にも含まれておらず、それ以降、標準に含まれていません。--enable-experimental-canvas-features コマンドライン フラグの背後で実装されるはずでしたが、誤って実装されていません。Chrome 60 では、この誤りは修正されています。このメソッドを使用していることを示すデータがないため、この変更は安全であると考えられています。

Chromium のバグ

Headers.prototype.getAll() を削除

Fetch の仕様の最新バージョンでは、Headers.prototype.getAll() 関数が削除されます。

削除の目的 | Chromestatus Tracker | Chromium のバグ

indexDB.webkitGetDatabaseNames() を削除する

この機能は、Indexed DB が Chrome で比較的新しく、プレフィックスを追加することが流行っていたときに追加されました。API は、オリジンの既存のデータベース名のリストを非同期で返します。これは十分に意味があるように思えます。

残念ながら、返された結果がすぐに古くなる可能性があるという設計上の欠陥があります。そのため、ロギングにしか使用できず、深刻なアプリケーション ロジックは使用できません。GitHub の問題には、別のアプローチが必要になる以前の説明へのリンクが含まれています。デベロッパーの間では関心が集まっていますが、ブラウザ間での進歩がないため、ライブラリの作成者によって問題が解決されています。

この機能を必要とするデベロッパーは、独自のソリューションを開発する必要があります。たとえば、Dexie.js のようなライブラリでは、グローバル テーブルを使用していますが、このテーブル自体も、データベース名をトラッキングするためのデータベースです。

この機能は Chrome 58 でサポートが終了し、削除されました。

削除の目的 | Chromestatus Tracker | Chromium のバグ

WEBKIT_KEYFRAMES_RULE と WEBKIT_KEYFRAME_RULE を削除する

標準以外の WEBKIT_KEYFRAMES_RULE および WEBKIT_KEYFRAME_RULE 定数は CSS ルールから削除されました。代わりに KEYFRAMES_RULEKEYFRAME_RULE を使用する必要があります。

削除の目的 | Chromestatus Tracker | Chromium のバグ

ユーザー インターフェース

beforeunload ダイアログでユーザー操作を要求する

Chrome 60 以降では、beforeunload ダイアログは、表示しようとしているフレームがユーザー操作またはユーザー操作を受け取った場合(または埋め込みフレームがそのような操作を受け取った場合)にのみ表示されます。ただし、これは beforeunload イベントのディスパッチに対する変更ではありません。これは単にダイアログを表示するかどうかが変わっただけです。

beforeunload ダイアログは、アプリモーダル ダイアログ ボックスです。そのため、本質的にユーザーにとって好意的です。つまり、ユーザーの操作に対してユーザーの判断を問います。この機能にはプラスの用途があります。たとえば、ナビゲーションによりデータが失われたときにユーザーに警告するためによく使用されます。

beforeunload ダイアログにテキストを表示するページは少し前に削除されましたが、beforeunload ダイアログは不正行為の誘因として残っています。特に beforeunload ダイアログは詐欺ウェブサイトの構成要素であり、音声の自動再生と脅迫的なテキストにより、Chromium の「このページを離れてもよろしいですか?」というメッセージにより不安を与える可能性があります。

Google は、beforeunload ダイアログを適切に使用して、スレッド処理を適切に行えるようにしたいと考えています。ダイアログは、ユーザーの状態が失われる可能性がある場合に有用です。ユーザーがページに対して一度も操作をしなかった場合、その状態が失われることはありません。したがって、そのような場合にダイアログを抑制しても、ユーザーデータの損失のリスクはありません。