...
この記事は Adam Ohren による Google Ads Developer Blog の記事 "Sunsetting Portofolio Enhanced CPC Bid Strategies" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

 2021 年 3 月 22 日より、ポートフォリオ(共有)拡張クリック単価(ECPC)入札戦略の提供を終了します。AdWords API と Google Ads API のすべてのバージョンで、以下の動作がブロックされます。
  • 新しいポートフォリオ ECPC 戦略の作成
  • ポートフォリオ ECPC 戦略のキャンペーンへのアタッチ
なお、標準(ポートフォリオでない)ECPC 戦略は影響を受けません。

影響を受けるポートフォリオ拡張クリック単価戦略
Google Ads API Bidding_strategy.type = BiddingStrategyType.ENHANCED_CPC
AdWords API SharedBiddingStrategy.type = MANUAL_CPC,

SharedBiddingStrategy.biddingScheme.enhancedCpcEnabled = TRUE


変更点の説明
新しいポートフォリオ ECPC 戦略の作成、ポートフォリオ ECPC 戦略のキャンペーンへのアタッチに関するすべての操作で、次のいずれかのエラーが発生します。

作成時のエラー アタッチ時のエラー
Google Ads API BIDDING_STRATEGY_NOT_SUPPORTED CANNOT_ATTACH_BIDDING_STRATEGY_TO_CAMPAIGN
AdWords API BIDDING_STRATEGY_NOT_SUPPORTED CANNOT_ATTACH_BIDDING_STRATEGY_TO_CAMPAIGN


移行の説明
標準 ECPC を優先するため、将来的にポートフォリオ ECPC 戦略は完全に削除する予定です。この変更に備えて、あらかじめすべてのポートフォリオ ECPC 戦略を標準 ECPC 戦略に移行しておくことができます。以下の手順をご覧ください。

残されたポートフォリオ ECPC キャンペーンと戦略は、後ほどすべて自動的に移行されます。移行の前には、このブログで最新情報を投稿します。

Google Ads API を使って自分で移行する場合
CampaignService.MutateCampaigns() を使い、manual_cpc.enhanced_cpc_enabled フィールドを true に設定してキャンペーンを更新します。リクエストには、忘れずに update_mask を設定してマッチングをしてください。
operations: [
  {
    update: {
      resource_mame: customers/CUSTOMER_ID/campaigns/CAMPAIGN_ID,
      manual_cpc: {
        enhanced_cpc_enabled: true
      }
    },
    update_mask: manual_cpc.enhanced_cpc_enabled
  }
]
AdWords API を使って自分で移行する場合
CampaignService.mutate() を使い、biddingStrategyTypeMANUAL_CPCbiddingScheme.enhancedCpc フィールドを true に設定してキャンペーンを更新します。
<operations>
  <operator>SET</operator>
  <operand>
    <id>CAMPAIGN_ID</id>
    <biddingStrategyConfiguration>
      <biddingStrategyType>MANUAL_CPC</biddingStrategyType>
      <biddingScheme>
        <enhancedCpcEnabled>true</enhancedCpcEnabled>
      </biddingScheme>
    </biddingStrategyConfiguration>
  </operand>
</operations>
ご質問やさらにサポートが必要なことがありましたら、フォーラムまたは googleadsapi-support@google.com にご連絡ください。

Reviewed by Thanet Knack Praneenararat - Ads Developer Relations Team

この記事は Android チーム、ソフトウェア エンジニア、Arvind Kumar Sugumar による Google Online Security Blog の記事 "New Password Checkup Feature Coming to Android" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

デジタル サービスが生活に身近になるにつれて、オンライン情報の安全を保つことの重要性も今までになく増しています。通常、パスワードはハッカーに対する防衛の第一線ですが、パスワードの漏洩につながりかねない情報流出の多さを考えれば、ユーザーは認証情報の保護に注意しなければならないことは明らかです。

これを簡単に行えるようにするため、2019 年に Password Checkup 機能を Chrome に導入し、Chrome に保存しているパスワードが漏洩した場合、通知が届くようになりました。今回、Google 自動入力を通してこの機能を Android アプリにも提供します。アプリで認証情報を自動入力したり保存したりすると、Chrome は侵害されたことがわかっている認証情報のリストと突き合わせて、そのパスワードが侵害されていた場合は、警告を表示します。そのプロンプトから Password Manager ページを開くこともできるので、そこで保存されているパスワードをすべてまとめて見直すこともできます。Android アプリでの Password Checkup は、Android 9 以降で Google 自動入力を使っているユーザーが利用できます。

Android デバイスで Autofill with Google を有効にする方法は次のとおりです

  1. スマートフォンの [ 設定 ] アプリを開く
  2. [ システム ] > [ 言語と入力 ] > [ 詳細設定 ] をタップする
  3. [ 自動入力サービス ] をタップする
  4. [ Google 自動入力サービス ] をタップして設定を有効化する

項目が見つからない場合は、こちらのページをご覧ください。デバイス メーカーから詳しい情報を得る方法が記載されています。

動作の仕組み

Google はユーザーのプライバシーを最優先に考えていますが、パスワードなどの機密データを扱う機能では特にそれを重視しています。Google 自動入力は Android の自動入力フレームワークがベースになっています。このフレームワークは、厳格かつ不変なプライバシーとセキュリティを遵守し、次の 2 つの場合にのみユーザーの認証情報にアクセスすることを保証します。1)ユーザーが Google アカウントに認証情報をすでに保存している場合。2)Android OS がユーザーに新しい認証情報を保存することを提案し、ユーザーがアカウントに認証情報を保存した場合。

ユーザーが認証情報を操作したとき(フォームに認証情報を入力する、または初めて保存するとき)、Chrome で使われているものと同じプライバシー保護 API を使い、Google が追跡している既知の侵害されたパスワードのリストにその認証情報が含まれていないかを確認します。

この実装では、以下の点が保証されています。

  • デバイスの外部に送信されるのは、暗号化された認証情報のハッシュのみ(データベースのパーティション化のため、ハッシュ化したユーザー名の最初の 3.25 バイトは暗号化せずに送信される)。
  • サーバーは、同じプレフィックスを持つ、侵害されたことがわかっている認証情報のリストを暗号化したハッシュとして返す。
  • 認証情報が実際に侵害されたものであるかどうかを判断する処理がユーザーのデバイス上で実行される。
  • サーバー(Google)は、暗号化されていないユーザーのパスワードのハッシュにはアクセスしない。クライアント(ユーザー)は、侵害された可能性がある認証情報の暗号化されていないハッシュのリストにはアクセスしない。

この API の内部処理の詳細については、Chrome チームによるこちらのブログをご覧ください。

その他のセキュリティ機能

Google 自動入力は、Password Checkup の他にも、データの保護に役立つ機能を提供します。

  • パスワード生成 : あまりに多くの認証情報を管理しなければならない場合、ユーザーは同じパスワードを複数のアカウントに流用しがちです。パスワード生成機能を使えば、Chrome が一意で安全なパスワードを生成し、Google アカウントへの保存まで行ってくれます。そのため、パスワードを覚える必要すらなくなります。Android アプリでは、パスワード フィールドを長押ししてポップアップ メニューから [ 自動入力 ] を選ぶことで、パスワード生成をリクエストできます。
  • 生体認証 : 認証情報や支払い情報を自動入力する際に生体認証を要求すると、デバイスの保護をさらに強化できます。生体認証は Google 自動入力設定から有効化できます。

いつものように、プロダクト全般のセキュリティ向上に関する最新情報をお届けする Google Security ブログにご注目ください。


Reviewed by Eiji Kitamura - Developer Relations Team

...
この記事は  Pierrick Voulet による Google Ads Developer Blog の記事 "The Invoice Service of Google Ads API is out of beta" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

 Google Ads API の v6 より、すべての API ユーザーで InvoiceService が利用可能になります。これより前の API バージョンでは、引き続き、許可されたアカウントのみを対象にこのサービスをサポートします。

このサービスを利用すると、Google 広告アカウントの月ごとの請求書を取得できます。返される各 Invoice には、データ(調整、管理コスト、税金、アカウント予算など)が含まれており、PDF ファイルとしてダウンロードできます。Google 広告管理者アカウントは、このデータを利用して顧客の請求書を自動処理できます。使ってみたい方は、専用のガイドをご覧ください。

ご質問やさらにサポートが必要なことがありましたら、フォーラムまたは googleadsapi-support@google.com にご連絡ください。

Reviewed by Thanet Knack Praneenararat - Ads Developer Relations Team

この記事はテクニカル プログラム マネージャー、Lutz Vahl による Chromium Blog の記事 "Heads Up: Restriction on SharedArrayBuffers are coming in M91" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Chrome 91(2021 年 5 月)より、すべてのプラットフォームで、SharedArrayBufferperformance.measureUserAgentSpecificMemory() などの API にアクセスする際にクロスオリジン分離が必須になります。Android では Chrome 88 からこの制限が適用されていますが、この対応により、デスクトップにも同じ制限が適用されます。

今後もこれらの API を使用する場合は、ページで以下のヘッダーを送信し、確実にページがクロスオリジン分離されるようにしてください。

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin

なお、これをすると、Cross-Origin-Resource-Policy ヘッダーか CORS ヘッダー(Access-Control-Allow-* など)で明示的にリソースを許可しない限り、そのページでクロスオリジンのコンテンツを読み込めなくなりますので、ご注意ください。

対応手順の詳細やその他の考慮事項については、web.dev のクロスオリジン分離有効化ガイドをご覧ください。


Reviewed by Eiji Kitamura - Developer Relations Team

...
この記事は Josh Radcliff による Google Ads Developer Blog の記事 "Announcing v6.1 of the Google Ads API" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

今日は、Google Ads API の v6.1 リリースをお知らせします。v6.1 の一部の機能を使うには、クライアント ライブラリとクライアントのコードをアップグレードする必要があります。更新版のクライアント ライブラリとコードサンプルは、来週公開されます。このバージョンには、互換性のない変更はありません。

主な機能は以下のとおりです。 さらに詳しく知りたい方へ
以下のリソースが役立ちます。 ご質問やさらにサポートが必要なことがありましたら、フォーラムからご連絡ください。

Reviewed by Thanet Knack Praneenararat - Ads Developer Relations Team

Firebase を活用しているマッチングアプリ「 」の事例が、昨年公開した に加え、今日、新たに に掲載されました。 タップルは 2018 年にリリースした新しい定期購入プラン「プレミアム プラン」とランディング ページを最適化するため、Firebase の複数のソリューションを活用して 7 日間の A/B テストをしました。 を使用することで、アプリの新バージョンをリリースすることなく、定期購入のプロンプトを動的に制御・変更することができ、 ...



Firebase を活用しているマッチングアプリ「タップル」の事例が、昨年公開した Android Developers サイトに加え、今日、新たに Firebase の Web サイトに掲載されました。

タップルは 2018 年にリリースした新しい定期購入プラン「プレミアム プラン」とランディング ページを最適化するため、Firebase の複数のソリューションを活用して 7 日間の A/B テストをしました。

Firebase Remote Config を使用することで、アプリの新バージョンをリリースすることなく、定期購入のプロンプトを動的に制御・変更することができ、Firebase A/B Testing では、最もパフォーマンスが良い有料会員サービスの推奨タイミングを把握。また、Firebase Crashlytics を使用してアプリの安定性を管理し、テスト中に何か問題が発生した場合には Remote Config を使用して迅速かつ簡単に機能をロールバックすることができました。

Firebase には、アプリの開発や最適化に役立つさまざまな機能が含まれています。公開済みのアプリでも、タップルのようにサービスを止めずに A/B テストを実施してその結果を評価できます。まだ Firebase をお使いになったことがない方は、ぜひこちらからお試しください。


Posted by Taro Sotome - Japan Apps Business Development and Tamao Imura - Developer Marketing Manager, Platforms and Ecosystems


この記事は Chromium Blog の記事 "Chrome 89 Beta: Advanced Hardware Interactions, Web Sharing on Desktop, and More" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


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


WebHID API

ヒューマン インターフェース デバイス(HID)には、新しすぎる、古すぎる、あまりにも一般的でないなどの理由で、システムのデバイス ドライバからアクセスできないロングテールなものがあります。WebHID API は、デバイス固有のロジックを JavaScript で実装する方法を提供することで、この問題を解決します。

ヒューマン インターフェース デバイスは、人間からの入力を受け取ったり、人間に対して出力を提供したりします。デバイスには、キーボード、ポインティング デバイス(マウス、タッチスクリーンなど)、ゲームパッドなどがあります。

たとえば、ゲームパッドのサポートにおいては、一般的でない HID デバイスにアクセスできないのは特に苦痛です。ゲームパッドの入出力はうまく標準化されておらず、多くの場合、ウェブブラウザに特定のデバイス向けのカスタム ロジックが必要となります。これはサステナブルでなく、古いデバイスや一般的でないデバイスといったロングテールがサポートされないことになります。

WebHID のオリジン トライアルは終了し、PC 向けの Chrome 89 でデフォルトで有効になります。使用方法については、一般的でない HID デバイスに接続するで確認できます。ウェブのヒューマン インターフェース デバイス : いくつかの簡単な例のデモもご覧ください。

Web NFC

NFC とは少量のデータを転送する近距離無線通信のことで、通常は専用の NFC デバイスとリーダー間の通信に使用します。建物に入るためにバッジをスキャンしたことがある方なら、NFC を使っているかもしれません。

Web NFC を利用すると、ウェブアプリから NFC タグの読み書きができます。これにより、博物館で展示情報を提供する、在庫を管理する、カンファレンスのバッジに情報を登録するなど、ウェブでさまざまな新しいユースケースを実現できるようになります。Web NFC は、Android 版の Chrome 89 でデフォルトで有効になります。

Chrome Dev Summit での Web NFC カードのデモ

NFC の読み書きは簡単なオペレーションで行うことができます。ペイロードの構築や解釈にいくつかの命令が必要になりますが、複雑ではありません。うれしいことに、ウェブで NFC デバイスと連携するという記事もありますので、ぜひご覧ください。実際に試してみることができるいくつかのサンプルもあります。次のようなイメージです。

NFC タグに文字列を書き込む :

if ("NDEFReader" in window) {
  const ndef = new NDEFReader();
  await ndef.write("Hello world!");
}

NFC タグのメッセージをスキャンする :

if ("NDEFReader" in window) {
  const ndef = new NDEFReader();
  await ndef.scan();
  ndef.onreading = ({ message }) => {
    console.log(`Records read from a NFC tag: ${message.records.length}`);
  };
}

Web Serial API

シリアルポートは、データをバイト単位で送受信できる双方向通信インターフェースです。Web Serial API は、この機能をウェブサイトで実現し、マイクロコントローラや 3D プリンタなどのデバイスを制御できるようにします。

教育、趣味、工業の分野では、すでにウェブページから周辺機器を制御しています。その場合、デバイスの制御にはアダプターやドライバのインストールが必要です。Web Serial API は、ウェブサイトと周辺機器の直接通信を可能にすることで、ユーザー エクスペリエンスを改善します。

Web Serial API のオリジン トライアルが終了し、PC で有効になります。GitHub でデモが公開されています。使用方法については、シリアルポートの読み書きを行うをご覧ください。

PC でのウェブ共有

デベロッパーは、ユーザーがソーシャル ネットワークで簡単にコンテンツを共有できるようにするため、各ソーシャル サービス用の共有ボタンを手動でサイトに組み込んでいます。このため、ユーザーが実際に使っているサービスで共有できないことが多く、ページサイズの肥大化やサードパーティ製コードによるセキュリティ リスクも発生しています。受信側では、共有ターゲットとして登録して他のアプリからの共有を受け取ることができるのは、プラットフォームのアプリのみです。

Android 版の Chrome では、Chrome 61 から 75 の間でこれらの機能の追加を始めました。Chrome 89 では、ウェブ共有が Windows と ChromeOS でも利用できるようになります。ただし、共有ターゲットとしての登録は ChromeOS のみでサポートされます。これらのプラットフォームでは、PC のサイトで navigator.share() を使うと、共有ダイアログ ボックスを開くことができます。また、ウェブアプリ マニフェストのエントリを追加すると、PWA を共有ターゲットにすることができます。

ウェブ共有についての情報は、Web Share API で OS の共有 UI を組み込むをご覧ください。PWA を共有ターゲットにすることについての詳しい情報は、Web Share Target API で共有データを受け取るをご覧ください。

オリジン トライアル

このバージョンの Chrome には、新しいオリジン トライアルはありません。現在のオリジン トライアルに登録するには、オリジン トライアル ダッシュボードをご覧ください。オリジン トライアル自体の詳細については、ウェブ デベロッパーのためのオリジン トライアル ガイドをご覧ください。

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

AVIF 画像のデコード

Chrome が AVIF コンテンツのデコードをネイティブにサポートします。Android と WebView は既存の AV1 デコーダを利用します(PC 版でのサポートは、Chrome 85 で追加されました)。AVIF は次世代の画像フォーマットで、Alliance for Open Media が標準化しています。AVIF のサポートには、主に 3 つの目的があります。

  • ページ読み込みを高速化して全般的なデータ消費量を削減するため、使用する帯域幅を減らします。AVIF を使うと、JPEG や WebP に比べて画像のファイルサイズを大幅に削減できます。
  • HDR カラーをサポートします。AVIF は、ウェブでの HDR 画像のサポートに向けた一歩です。JPEG の色深度は、実質的に 8 ビットに限られています。輝度、色ビット深度、色域の面でディスプレイの機能が強化されていることから、JPEG では失われる画像データを保存したいと考えるウェブ関係者が増えています。
  • エコシステムの関心に対応します。ウェブにおいて大きな存在感を持つ企業が、ウェブに AVIF 画像を掲載することに興味を示しています。

Cross-Origin Opener Policy Reporting API

新しい Reporting API は、Cross-Origin Opener Policy (COOP) のデプロイに役立ちます。この API は、COOP が強制される際の違反の報告に加え、COOP の報告のみのモードも提供します。COOP の報告のみのモードは COOP を強制しませんが、COOP を強制していれば発生していた潜在的な違反を報告します。デベロッパーは、Chrome DevTools で Reporting API が有効になっているかを確認できます。

ウェブアプリ マニフェストでの display のオーバーライド

ウェブアプリ マニフェストに display_override フィールドが新しく追加されます。これにより、デベロッパーが display フィールドのフォールバック チェーンを明示的に指定できるようになります。次の例では、"minimal-ui""standalone" にフォールバックする指定をしています。

{
  "display": "standalone",
  "display_override": ["minimal-ui"],
}

この API は、高度なユースケースと表示モードを想定したもので、機能は限られています。詳しくは、Chrome Status のエントリをご覧ください。

ReadableStreamDefaultController インターフェースの公開

Chrome は、他の ReadableStream 関連のクラスと同じように、グローバル オブジェクトで ReadableStreamDefaultController インターフェースを公開します。これにより、インスタンスをストリームのコンストラクタの内部で作成しなければならないという、これまでの制限がなくなります。

performance.measureUserAgentSpecificMemory()

この機能により、ウェブページのメモリ使用量を見積もる performance.measureUserAgentSpecificMemory() 関数が追加されます。このメソッドは COOP/COEP の制限を受けるので、これを使うにはウェブサイトがクロスオリジン分離されている必要があります。

潜在的に信頼できる data: URL

現在のウェブ標準に準拠するため、Chrome はすべての data: URL を潜在的に信頼できるものとして扱います
これは、認証や機密性に関して最低限の基準しか満たされていない場合でも、ある機能を有効化するためには、URL が安全かどうかを評価しなければならないことがあるためです。ウェブ標準は、それを実現するために「潜在的に信頼できる URL」の定義を使いますが、最新版の Secure Contexts 仕様では、そこに "data" スキームの URL が含まれています。これまでの Blink は、いくつかの data: URL のみを潜在的に信頼できるものとして扱っていました。

Streams API: バイト ストリーム

ストリーム API では、データ ストリームの作成、構成、使用のためのユビキタスで相互運用可能なプリミティブが提供されます。Chrome は、バイトを表すストリームで拡張バージョンの読み取り可能ストリームをサポートし、バイトを効率的に扱います。具体的には、コピーの回数を最低限にとどめます。


バイト ストリームは、Bring Your Own Buffer(BYOB)のリーダーを取得できます。デフォルトの実装では、ウェブソケットの場合は文字列や配列バッファなどのさまざまな種類の出力を指定できますが、バイト ストリームではバイト出力が保証されます。さらに、BYOB リーダーを扱えることで、安定性のメリットももたらされます。バッファがデタッチされれば、同じバッファに 2 回書き込まれないことが保証され、競合状態を回避できるためです。BYOB リーダーではバッファが再利用されるため、読み取りのたびにガベージ コレクションを行う必要もありません。

SVG 要素での完全な 'filter' プロパティ構文のサポート

Chrome の SVG 要素で 'filter' プロパティの完全な構文が利用できるようになります。これまでは、1 つの url() 参照しかサポートされませんでした。これにより、blur()sepia()grayscale() などのフィルタ関数を SVG 要素と非 SVG 要素の両方に適用できるようになります。また、'filter' のプラットフォーム サポートの均一性が増し、一部の「定型」エフェクトを適用しやすくなります。この機能がないときは、grayscale()blur() といった基本的なフィルタを使う場合でも、SVG の完全な <filter> 要素定義を使う必要がありました。

WebAuthentication API: ResidentKeyRequirement と credProps エクステンション

Chrome で Web Authentication API に関連する 2 つの新機能がサポートされます。AuthenticatorSelectionCriteria.residentKey プロパティは、ウェブ認証のクレデンシャル登録において、クライアント側で検出可能なクレデンシャルを作成するかどうかを指定します。

Web Authentication の credProps エクステンションは、作成したクレデンシャルがクライアント側で検出可能(discoverable)かどうかをリライング パーティに示します。「クライアント側で検出可能なクレデンシャル」とは、WebAuthn API リクエストでリライング パーティがクレデンシャル ID を提供することなくチャレンジを行えるタイプの WebAuthn クレデンシャルです。ブラウザは、指定された認証器(外部セキュリティ キーか組み込みのもの)からのすべての検出可能なクレデンシャル(discoverable credentials)のリストを表示し、ユーザーがログインに使うものを選択できるようにします。

CSS

::target-text 疑似要素

scroll-to-text フラグメントにデフォルトのユーザー エージェントのハイライトとは違うスタイルを設定できるようにするため、ハイライト疑似要素を追加します。

フロー関連の角丸プロパティ

フロー関連の角丸プロパティで、物理プロパティではなく論理マッピングを使って角を制御できるようになります。これにより、ページの向きや表記の方向によって異なる角丸の半径を設定することも可能になります。また、Chrome が CSS Logical Properties and Values 仕様に準拠することになります。以下の論理プロパティが追加されました。

  • border-start-start-radius
  • border-start-end-radius
  • border-end-start-radius
  • border-end-end-radius

強制カラー プロパティ

forced-colors メディア機能は、ページでユーザーが選択した限定カラーパレットをユーザー エージェントが強制しているかどうかを検出します。

強制カラー調整プロパティ

forced-color-adjust プロパティを使うと、強制カラーモードから特定の要素を除外し、CSS で完全にカラーを制御する状態に戻すことができます。

JavaScript

このバージョンの Chrome には、V8 JavaScript エンジンのバージョン 8.9 が組み込まれます。具体的には、以下の変更点が含まれます。最新の機能リストをすべて確認したい方は、V8 リリースノートをご覧ください。

トップレベルの await

Chrome では、JavaScript モジュールのトップレベルで await キーワードが許可されるようになりました。これにより、モジュールの読み込み処理に非同期呼び出しをシームレスに統合できるようになります。現在のところ、この機能はモジュールを async 関数でラップすることで実現していますが、これにより複雑さを依存モジュール側にとどめつつ、実装の詳細を公開しています。

デベロッパー ノート

EXIF の画像の向き

クロスオリジン画像の向きの判定に常に EXIF 情報が利用されるようになります。つまり、CSS で image-orientation: none を設定しても、安全でないオリジンの画像には反映されなくなります。この仕様変更に関する議論は、CSS ワーキング グループ ドラフトに記載されています。

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

このバージョンの Chrome では、以下のサポートの終了および機能の削除が行われます。現在サポートが終了している機能および以前に削除された機能のリストは、ChromeStatus.com をご覧ください。

<link rel=prerender> のプレフィックス付きイベントの削除

<link rel=prerender> から発行されるレガシーなプレフィックス付きイベント(webkitprerenderstartwebkitprerenderstopwebkitprerenderloadwebkitprerenderdomcontentloaded)が Chrome から削除されます

noopener で開いたウィンドウでの sessionStorage の複製停止

ウィンドウを noopener で開いた場合、Chrome はオープン元の sessionStorage を複製しなくなります。代わりに、空の sessionStorage 名前空間が開始されます。これにより、Chrome が HTML 仕様に準拠します。


Reviewed by Eiji Kitamura - Developer Relations Team