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

Joe Medley
Joe Medley

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

セキュリティ

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

Chrome 37 以降でサポートされている Web Crypto API は、常に安全でないオリジンで動作しています。Chrome の長年のポリシーである強力な機能には安全な送信元を優先するため、crypto.subtle は安全な送信元にのみ表示されることはありません。

削除の目的 | Chromium バグ

コンテンツによって開始されたデータ URL へのトップフレーム ナビゲーションを削除

技術に精通していないブラウザ ユーザーには馴染みがないため、なりすましやフィッシング攻撃で data: スキームが使用されるケースが増えています。これを防ぐため、ウェブページがトップフレームで data: URL を読み込まないようにブロックしています。これは、<a> タグ、window.openwindow.location、および同様のメカニズムに適用されます。data: スキームは、ページによって読み込まれるリソースでも引き続き機能します。

この機能は Chrome 58 で非推奨となり、削除されました。

削除の意向 | Chromestatus トラッカー | Chromium のバグ

一部の blob の navigator.sendBeacon() を一時的に無効化

navigator.sendBeacon() 関数は Chrome 39 から利用可能になりました。元の実装では、関数の data 引数に、CORS セーフリストに登録されていない任意の blob を含めることができます。これは潜在的なセキュリティ上の脅威であると考えられますが、まだ悪用しようとする者はいません。現時点では合理的な即時修正がないため、一時的に、タイプが CORS セーフリストに登録されていない blob で sendBeacon() を呼び出すことができなくなります。

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

Chromium のバグ

CSS

シャドウ ピアリング子孫コンビネーターが子孫コンビネーターのように動作するようにする

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

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

削除の意向 | Chromestatus トラッカー | Chromium のバグ

JavaScript

RTCPeerConnection.getStreamById() の非推奨と削除

getStreamById() は、ほぼ 2 年前に WebRTC 仕様から削除されました。他のほとんどのブラウザでは、すでに実装から削除されています。この関数はほとんど使用されていないと思われますが、getStreamById() が引き続きサポートされている Safari 以外の Edge と WebKit ベースのブラウザとの相互運用性に関するリスクが若干あると見られています。代替の実装が必要なデベロッパーは、下記の削除通知でサンプルコードを確認できます。

削除は Chrome 62 で実施されます。

削除の意向 | Chromestatus トラッカー | Chromium のバグ

SVGPathElement.getPathSegAtLength を非推奨に

getPathSegAtLength() は 2 年以上前に SVG 仕様から削除されました。httparchive でこのメソッドのヒットはごく少数であるため、Chrome 60 で非推奨になります。削除は 10 月上旬または中旬にリリースされる Chrome 62 で予定されています。

サポート終了の予定 | Chromestatus トラッカー | Chromium バグ

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

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

Chromium のバグ

Headers.prototype.getAll() を削除

Headers.prototype.getAll() 関数は、最新バージョンのフェッチ仕様に基づいて削除されます。

削除の意向 | Chromestatus トラッカー | Chromium のバグ

indexedDB.webkitGetDatabaseNames() を削除

この機能は、Indexed DB が Chrome で比較的新しい機能で、接頭辞が流行していたときに追加されました。API は、オリジン内の既存のデータベース名のリストを非同期で返します。これは十分に理にかなっています。

残念ながら、この設計には欠陥があります。結果は返された直後に無効になる可能性があるため、真剣なアプリケーション ロジックではなく、ロギングにのみ使用できます。GitHub の問題には、別のアプローチが必要な代替案に関する以前のディスカッションへのリンクが記載されています。デベロッパーの関心は断続的にありますが、クロスブラウザの進展がないため、ライブラリ作成者によって問題は回避されています。

この機能を必要とするデベロッパーは、独自のソリューションを開発する必要があります。たとえば、Dexie.js などのライブラリは、データベースの名前を追跡する別のデータベースであるグローバル テーブルを使用します。

この機能は Chrome 58 で非推奨となり、削除されました。

削除の意向 | Chromestatus トラッカー | Chromium のバグ

WEBKIT_KEYFRAMES_RULE と WEBKIT_KEYFRAME_RULE を削除

標準外の WEBKIT_KEYFRAMES_RULE 定数と WEBKIT_KEYFRAME_RULE 定数が CSS ルールから削除されました。デベロッパーは代わりに KEYFRAMES_RULEKEYFRAME_RULE を使用する必要があります。

削除の意向 | Chromestatus トラッカー | Chromium のバグ

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

beforeunload ダイアログでユーザー操作を必須にする

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

beforeunload ダイアログは、アプリ モーダルのダイアログ ボックスです。そのため、本質的にユーザーに不利です。つまり、ユーザーの選択に疑問を呈してユーザーの操作に応答します。この機能には有益な用途もあります。たとえば、ナビゲーションによってデータが失われる場合にユーザーに警告するためによく使用されます。

ページが beforeunload ダイアログのテキストを提供できる機能はしばらく前に削除されましたが、beforeunload ダイアログは不正行為のベクトルとして残っています。特に、beforeunload ダイアログは詐欺サイトの要素です。自動再生音声と脅迫的なテキストにより、Chromium が提供する「このページを離れようとしていますか?」というメッセージが不安を煽る文脈になります。

Google は、beforeunload ダイアログの適切な使用のみを許可したいと考えています。ダイアログを適切に使用するのは、ユーザーが状態を失う可能性がある場合です。ユーザーがページを操作していない場合、ユーザーの状態が失われることはありません。そのため、この場合はダイアログを抑制してもユーザーデータが失われるリスクはありません。