Chrome 96: 条件に応じたフォーカスや優先度ヒントなどの新機能

この記事は Chromium Blog の記事 “Chrome 96 Beta: Conditional Focus, Priority Hints, and More” を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


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

3 桁のバージョン番号に対する準備

来年には、Chrome でバージョン 100 がリリースされます。つまり、Chrome のユーザー エージェント文字列で報告されるバージョン番号の桁が増えます。サイトオーナーが新しい文字列をテストしやすくするために、Chrome 96 では、Chrome のユーザー エージェント文字列として「100」が返されるようにするランタイム フラグが導入されています。chrome://flags/#force-major-version-to-100 と呼ばれるこの新しいフラグは、Chrome 96 以降で利用できます。

オリジン トライアル

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

新しいオリジン トライアル

Conditional Focus

現在、他のウィンドウやタブをキャプチャするアプリケーションには、呼び出し元のアイテムやキャプチャするアイテムにフォーカスするかどうかをコントロールする方法がありません(ビデオ会議アプリのプレゼンテーション機能を思い浮かべてください)。Chrome 96 では、新しい focus() メソッドをサポートする FocusableMediaStreamTrack と呼ばれる MediaStreamTrack のサブクラスを使用して、このコントロールを可能にしました。次のコードをご覧ください。

stream = await navigator.mediaDevices.getDisplayMedia();
let [track] = stream.getVideoTracks();

このコードでは、以前は getVideoTracks()MediaStreamTrack オブジェクトの配列を返していましたが、FocusableMediaStreamTrack オブジェクトを返すようになります(Chrome 97 では、返されるオブジェクトが BrowserCaptureMediaStreamTrack に変更される予定です。本記事の執筆時点で、Canary 版ではすでに新しいオブジェクトが返されるようになっています)。

フォーカスするディスプレイ メディアを決定するには、このコードの次の行で "focus-captured-surface" を指定して track.focus() を呼び出し、新しくキャプチャするウィンドウやタブにフォーカスするか、"no-focus-change" を指定してこのメソッドを呼び出し、呼び出し元のウィンドウにフォーカスし続けます。Chrome 96 以降では、デモコードを試して、この機能の動作を確認できます。

Priority Hints

Priority Hints では、デベロッパーが設定する "importance" 属性が導入され、計算されるリソースの優先度を変更することができます。サポートされる importance 属性の値は、"auto""low"、と "high" です。Priority Hints は、リソースの相対的な重要度をブラウザに示し、リソースが読み込まれる順序をより細かくコントロールできるようにします。ブラウザでは、リソースのタイプ、可視性、プリロードのステータスなど、多くの要素がリソースの優先度に影響を及ぼします。

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

プリフライトなしに単純な Range ヘッダー値を許可

プリフライト リクエストなしに、単純な Range ヘッダーを指定してリクエストを送信できるようになりました。CORS リクエストでは、プリフライト リクエストをトリガーせずに、Range ヘッダーを限定的な方法(1 つの有効な範囲のみ)で使用できます。

デスクトップのバックフォワード キャッシュ

バックフォワード キャッシュにページが格納され、クロスサイト ナビゲーションをした後でも、以前にアクセスしたページへの即時ナビゲーションが可能になります。

Cross-Origin-Embedder-Policy: credentialless

Cross-Origin-Embedder-Policy には、クロスオリジン no-cors リクエストで認証情報(Cookie やクライアント証明書など)を省略できるようにする新しい credentialless オプションが追加されます。COEP:require-corp と同じように、クロスオリジン分離も有効化できます。

SharedArrayBuffer を使い続けたいサイトでは、クロスオリジン分離をオプトインする必要があります。COEP: require-corp を使用して、クロスオリジン分離のオプトインを大規模に導入することは難しく、すべてのサブリソースで明示的にオプトインしなければならなくなります。これが問題にならないサイトもありますが、ユーザーからコンテンツを収集するサイト(Google Earth、ソーシャル メディア全般、フォーラムなど)では、依存関係の問題が発生します。

CSS

:autofill 疑似クラス

新しい autofill 疑似クラスを使用すると、自動入力されるフォーム要素のスタイルを設定できます。これは、:-webkit-autofill 疑似クラスの標準化として導入されており、WebKit ではすでにサポートされています。Firefox は、この標準バージョンをサポートします。

封じ込めが適用される場合に body スタイルからビューポートへの伝播を無効化

writing-mode、direction、background など、一部のプロパティは、body からビューポートに伝播されます。CSS コンテナクエリの無限ループを防ぐために、仕様と実装が変更され、HTML または BODY にレイアウトの封じ込めが適用される際にこれらのプロパティが伝播されなくなりました。

font-synthesis プロパティ

font-synthesis CSS プロパティは、フォント ファミリーにフェイスがない場合、ユーザー エージェントが斜体、太字、小型英大文字のフォント フェイスを合成できるようにするかどうかをコントロールします。

EME MediaKeySession が閉じられた理由

MediaKeySession.closed プロパティは、enum を使用して、MediaKeySession オブジェクトが閉じられた理由を示すようになります。この closed プロパティは、セッションが閉じたときに解決される Promise を返します。以前は Promise が解決されるだけでしたが、文字列として解決されるようになり、閉じられた理由を示します。返される文字列は、"internal-error""closed-by-application""release-acknowledged""hardware-context-reset""resource-evicted" のいずれかです。

HTTPS DNS レコードでの HTTP から HTTPS へのリダイレクト

Chrome では、DNS(ドメイン名サービス)から HTTPS レコードが利用できる場合は、常に HTTPS 経由でウェブサイトに接続します。

EventTiming の interactionID

PerformanceEventTiming インターフェースに interactiveID と呼ばれる属性が含まれるようになりました。これは、ブラウザが生成する ID であり、複数の PerformanceEventTiming エントリが同じユーザー操作に対応する場合、これらのエントリをリンクできるようにします。現在、デベロッパーは Event Timing API を使用して、関心のあるイベントのパフォーマンス データを収集できます。ただし、同じユーザー操作に対応するイベントをリンクすることは困難です。たとえば、ユーザーがタップしたときなら、pointerdownmousedownpointerupmouseupclick など、多くのイベントが生成されます。

新しいメディアクエリ : prefers-contrast

Chrome は、 'prefers-contrast' と呼ばれる新しいメディアクエリをサポートします。そのため、ウェブ制作者は、オペレーティング システムで設定されたユーザーのコントラスト設定(具体的には、macOS のコントラストを強調したモードと Windows のハイ コントラスト モード)にウェブ コンテンツを合わせることができます。有効な選択肢は、'more''less''custom'、または 'no-preference' です。

デスクトップ PWA の一意の ID

ウェブアプリ マニフェストで任意の id フィールドがサポートされ、ウェブアプリをグローバルに特定できるようになりました。id フィールドがない場合、PWA は start_url にフォールバックします。現時点で、このフィールドはデスクトップのみでサポートされます。

PWA の URL プロトコル ハンドラ登録

ウェブ アプリケーションがインストール マニフェストを使用して、カスタム URL プロトコル / スキームのハンドラとして自身を登録できるようにします。多くの場合、オペレーティング システム アプリケーションは自身をプロトコル ハンドラとして登録して、見つけやすさと使用率を向上します。ウェブサイトは、すでに registerProtocolHandler() を介してスキームを処理するように登録できます。この新機能はもう一歩踏み込んで、カスタム スキーム リンクが呼び出されたときに、ウェブアプリを直接起動できるようにします。

WebAssembly

コンテンツ セキュリティ ポリシー

Chrome のコンテンツ セキュリティ ポリシーが強化され、WebAssembly との相互運用性が向上しています。wasm-unsafe-eval は、WebAssembly の実行をコントロールします(JavaScript の実行には影響しません)。また、script-src ポリシーに WebAssembly が含まれるようになりました。

参照型

WebAssembly モジュールで JavaScript オブジェクトや DOM オブジェクトへの参照を保持できるようになりました。具体的には、これらの参照は、引数として渡したり、ローカル変数やグローバル変数に格納したり、WebAssembly.Table オブジェクトに格納したりできます。

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

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

PaymentRequest API の “basic-card” 支払い方法

PaymentRequest API では、“basic-card” 支払い方法が非推奨となっています。その使用率は低いうえ、低下し続けています。この支払い方法の購入手続きまでの時間や購入完了率は、他の支払い方法を下回っています。デベロッパーは、代わりとして他の支払い方法に切り替えることができます。たとえば、Google Pay、Apple Pay、Samsung Pay などの支払い方法です。

削除までのタイムライン :

  • Chrome 96: “basic-card” 支払い方法は、レポーティング API で非推奨となります。
  • Chrome 100: “basic-card” 支払い方法は削除される予定です。

Reviewed by Eiji Kitamura – Developer Relations Team
<!—->

Google for Startups Accelerator メンターを募集します

Google for Startups Accelerator のメンターを募集します。Google はテクノロジーが社会をより良くしていくと考えています。私たちは社会の大きな課題を解決するためのアイデアを持つスタートアップをテクノロジーの力で支援したいと考えています。そのため、Google では、Google for Startups Accelerator というスタートアップを支援するアクセラレータプログラムを日本でも継続的に行っております。この度、Google for Startu…

Payment Request API で "basic-card" 支払い方法の提供が終了

この記事は Chrome チーム、デベロッパー アドボケート、Eiji Kitamura による Chromium Blog の記事 “Sunsetting the ‘basic-card’ payment method in the Payment Request API” を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


Payment Request API推奨が近いウェブ標準であり、ウェブ デベロッパーが手間のかからない安全な支払いフローを簡単に構築できるようにすることを目的としています。ブラウザは、販売者のウェブサイトと「支払いハンドラ」との間のフローを容易にします。支払いハンドラは、ブラウザ、ユーザーのモバイル デバイスにインストールされたネイティブ アプリ、またはプログレッシブ ウェブアプリに組み込むことができます。現在、デベロッパーは Payment Request API を使用して、ほとんどのプラットフォームの Chrome で利用できる “basic-card” や Google Pay、Safari の Apple Pay、Google Play での Digital Goods API、Chrome の Secure Payment Confirmation など、いくつかの支払い方法にアクセスできます。

Google は昨年の初めに、iOS 版 Chrome に加えて、他のプラットフォームでも “basic-card” 支払いハンドラのサポートを終了する予定であることを発表しました。通常、ブラウザに組み込まれている支払い方法である “basic-card” は、クレジット カード番号を覚えたり、手動で入力したりすることなく、その番号を簡単に入力できるようにします。この支払い方法は、フォームベースのクレジット カード支払いからアプリベースのトークン化されたカード支払いへの移行をスムーズにするために設計されました。Web Payments WG は、アプリベースの支払いを促進する(また、その他のいくつかの理由で)という目標を達成するために、“basic-card” を仕様から削除することを決定しました。

Chrome バージョン 96 以降で “basic-card” 支払い方法が使われると、DevTools コンソールに警告メッセージが表示されます(レポーティング API のレポートも作成されます)。バージョン 100 では、”basic-card” 支払い方法が利用できなくなり、他の使用可能な支払い方法が指定されていない限り、canMakePayment()false を返します。これは、Android、macOS、Windows、Linux、Chrome OS など、すべてのプラットフォームに適用されます。

Payment Request API で “basic-card” 支払いハンドラを使用している場合は、この支払いハンドラをできるだけ早く削除して、Google Pay や Samsung Pay などの代替支払い方法を使用することをおすすめします。

Reviewed by Eiji Kitamura – Developer Relations Team
<!—->

Google Dev Library のご紹介––デベロッパーのための新しいオープンソース プラットフォーム

この記事は Google Developers Blog の記事 “What is Google’s Dev Library––a new open-source platform for developers” を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Dev Library ロゴのバナー 世界中のデベロッパーが、オープンソースのツールやチュートリアルを作成しています。しかし、それを見つけてもらうのは簡単なことではありません。多くの場合、公開されるコンテンツは、GitHub から Medium まで、たくさんのサイトにまたがっています。そこで Google は、Google のテクノロジーに関連する優れたプロジェクトを 1 か所にまとめて紹介する場所を作ることを決定し、Dev Library を公開しました。Dev Library は、Google のテクノロジーを使って構築されたプロジェクトや、それに関する記事を厳選して集めたアーカイブです。

このプラットフォームには、ブログ投稿やオープンソース ツールが掲載され、わかりやすい操作で閲覧できるようになっています。プロダクトの領域として、機械学習、Flutter、Firebase、Angular、クラウド、Android を扱っています。

Dev Library がほかと異なる点は何ですか?

皆さんが申請したすべての記事やプロジェクトがサイトに掲載されるとは限りません。Google のエキスパートからなるチームが、それぞれのトピックの正確性や関連性を吟味します。そのため、サイトに掲載されたコンテンツは、Google が承認したことを意味しています。

どのように役立ちますか?

目につきやすくなります。広い専門性を持っているデベロッパーでも、その知識をアピールするのは大変なことです。Dev Library は、皆さんが世界に向かって「ねえ!すばらしいプロジェクトを作ったんだけど、ぜひ見てみない?」と声をあげる方法の 1 つです。

さらに、同じように Dev Library でプロジェクトを公開している貢献者仲間のネットワークを得ることもできます。

貢献者の皆さんによる作業を応援するため、1 人ずつ専用の作者ページを作成して、1 か所でプロジェクトを一覧できるようにしています。

Dev Library ではどんなコンテンツが見つかりますか?

このサイトに幅広いコンテンツが掲載されている証として、公開されているコンテンツや作成したデベロッパーの動画インタビューの一部を紹介しましょう。

最終的な目的は何ですか?

優れた文章を書けるデベロッパーを増やすことです。あらゆる種類のプロジェクトを経験し、知識を備えているにもかかわらず、それを表現するのに苦労するデベロッパーを見かけることは少なくありません。しかし、自分の作業について文章化できるデベロッパーがもっと必要です。経験してきた苦労や実際に書いたコードブロック、プロジェクトを形にする方法といった内容です。

Dev Library を通じて、変化を生み出したいと思っています。

優れた文章を書けるデベロッパーを増やし、マーケティングの質を向上させ、詳しい説明を待っている世界中のユーザーにアプローチしてもらえることを期待しています。

どうすれば Dev Library をサポートできますか?

Dev Library をさらに成長させるために、皆さんにご協力いただける方法が 2 つあります。

  1. Dev Library で公開したい優れたコンテンツをお持ちの方は、こちらからレビューの申請をしてください。
  2. フィードバックも歓迎しています。Dev Library サイトに追加や変更の希望がある方は、こちらの簡単なフィードバック フォームに入力するか、GitHub で Issue を送信してください。

皆さんからの申請やフィードバックを楽しみにしております。

Dev Library が皆さんのオープンソース作品を公開するすばらしい場所になるように、ご協力をお願いいたします。

Google OAuth の段階的な認証の改善について

この記事はプロダクト マネージャー、Vikrant Rana、グループ プロダクト マネージャー、Badi Azad による Google Developers Blog の記事 “Google OAuth incremental authorization improvement” を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


概要

Google Identity は、データの保護において Google を信頼してくださっている Google アカウント ユーザーに充実した機能を提供すべく、日々努力を重ねています。同時に、ユーザーにすばらしい体験を提供するアプリを作るデベロッパー コミュニティにも貢献したいと考えています。Google とデベロッパーとの連携により、ユーザーは次の 3 つの重要な方法でデータの共有を管理できるようになっています。

  1. 誰が自分のアカウント データにアクセスできるかを決定する際に、ユーザーは対象を細かく制御できます
  2. ユーザーが Google アカウントのデータをアプリと共有することにした場合、簡単かつ安全な操作で共有できます
  3. 具体的にどんなデータをアプリと共有しているかを、ユーザーに明らかにします

現在行っていること

以上の内容を実現するため、ユーザーが簡単にアプリとデータを共有できるようにする OAuth の同意操作についてお知らせします。この操作は、一度に 1 つのスコープしかリクエストできない段階的な認証を使っているアプリで、同意コンバージョン操作を改善するものでもあります。ユーザーは、この種のリクエストに対して、1 回のタップで簡単に共有できるようになります。
サンプルアプリがアカウント情報にアクセスする際のこれまでの画面と新しい画面のスクリーンショットの比較
これまでの画面                                           新しい画面

簡単な復習

OAuth の同意フローに対して行ってきた作業の全体像が把握できるように、これまでの改善内容を簡単にまとめておきましょう。

2019 年の中頃に、同意画面を大幅に改訂し、アプリと共有するアカウント データをユーザーが細かく制御できるようにしました。このフローでは、アプリが複数の Google リソースへのアクセスをリクエストすると、ユーザーには 1 つのスコープにつき 1 つの画面が表示されていました。

2021 年 7 月には、ユーザーが共有するデータを細かく制御できる機能は維持したまま、複数の権限リクエストを 1 つの画面にまとめました。今回の変更は、この操作の改善の延長線上にあります。
サンプルアプリがアクセスできる内容を選択する画面のスクリーンショット
Identity チームは、今後もフィードバックを集め、Google Identity サービスやアカウント データの共有に関する全般的なユーザー エクスペリエンスをさらに向上させたいと考えています。

デベロッパーが行うべきこと

アプリで必要になる変更は何もありません。ただし、段階的な認証を使って、アプリが必要とするときに一度に 1 つずつリソースをリクエストすることをお勧めします。そうすることで、アカウント データをリクエストする必要性がユーザーに伝わりやすくなるので、同意コンバージョン率が増加するはずです。段階的な認証の詳細は、デベロッパー ガイドでご確認ください。

一度に複数のリソースが必要なアプリで一部しか同意されなかった場合は、問題が起きないように処理し、OAuth 2.0 ポリシーに従って適切に機能を縮退してください。

関連コンテンツ

Reviewed by Eiji Kitamura – Developer Relations Team<!—->

Chrome OS での Chrome アプリのサポートを延長

この記事は Chrome、テクニカル プログラム マネージャー、Paul Rossman による Chromium Blog の記事 “Extending Chrome App Support on Chrome OS” を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。この度、以前にお知らせした Chrome アプリのサポート スケジュールに関する重要な変更点について発表します。企業や教育関係のお客様やパートナー様からのフィードバックを踏まえ、Chrome OS をお使いの上記ユーザーに…

次世代のモバイル デバイス向けマップのご紹介

この記事は Google Maps Platform プロダクト マネージャー Ryan Cassidy による Google Cloud Blog の記事 “Meet the next generation of mobile-optimized maps” を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。カスタマイズされた地図は、スムーズなエクスペリエンスを提供するうえでの鍵となり得るもので、ユーザーを惹き付け、ユーザーの関心を集めてくれます。自由度の高い地図は、不動産会社が地図上の…

デフォルトのベースマップとして、強化されたマップスタイルを11 月に展開します

この記事は Google Maps Platform プロダクト マネージャー Alicia Sullivan による Google Cloud Blog の記事 “Enhanced map style rolling out as default basemap in November” を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。昨年、地図全体における自然特性の描写を強化したことで、Google マップの外観が進化しました。同時に、このスタイルは Google Maps Plat…

Google Cloud Learn 初開催のラーニング イベントのご案内

Google Cloud Learn 12 月 9 日(木)詳細・お申し込みはこちらCloud Learn に参加しませんか?このイベントは、Google Cloud を学びたい皆さまにご参加いただける、初開催の無料オンライン イベントです。あらゆるレベルの開発者や IT プロフェッショナル、データ エンジニアを主な対象とし、「なぜクラウドを学ぶのか」「エンジニアの未来とは」という視点でスキルアップやキャリア開発について考え、すぐにスタートできるよう支援いたします。クラウド人材育成に関わる…