headless 曰く、

Google は 16 日、Chrome 拡張の Manifest V3 (MV3) 移行計画再開を発表した (Chrome for Developers のブログ記事、 Google グループ投稿、 The Verge の記事、 Android Police の記事)。

より信頼できる Chrome 拡張を目指す MV3 移行だが、Manifest V2 (MV2) が備える高度なコンテンツブロックに適した機能が使えなくなることなどへの反対も強かった。MV3 の API 実装が進んでいないこともあって移行計画は延期が繰り返されていたが、その後実装は進み、拡張機能開発者コミュニティでの支持も広がっていることから移行計画を再開するという。

MV2 の無効化は Stable 以外のチャネル (Canary、Dev、Beta) で早ければ 2024 年 6 月、Chrome 127 以降で開始される。ロールアウトの影響を受けたユーザーは MV2 拡張機能が自動的に無効化され、新たに MV2 拡張機能を Chrome ウェブストアからインストールできなくなる。また、2024 年 6 月には MV2 拡張機能から「おすすめ」バッジが外される。MV2 を引き続き必要とするエンタープライズ向けの ExtensionManifestV2Availability ポリシーは 2025 年 6 月まで利用できるが、拡張機能開発者には 2024 年 6 月までの MV3 移行が推奨されている。

headless 曰く、

Google が提唱するウェブのエクスペリエンスに関する指標 Core Web Vitals (CWV) により、2023 年だけで Chrome ユーザーの待ち時間が延べ 10,000 年以上短縮されたそうだ ( Chromium Blog の記事)。

CWV は 2020 年に Google が発表した Web Vitals のサブセットであり、現在では 40% 以上のサイトがすべての CWV 指標を満たしているという。これにより Chrome のページ読み込み速度は平均 166 ミリ秒速くなっており、Android 版 Chrome で 8,000 年相当、Windows 版 Chrome で 2,000 年相当の待ち時間が短縮されたそうだ。また、ユーザーの入力に対する応答時間は Android 版 Chrome で 800 年相当、Windows 版 Chrome で 450 年相当が短縮されたとのことだ。

headless 曰く、

Microsoft Edge では Google Chrome のダウンロード時にさまざまな方法でブラウザーの乗り換えを防ごうとするが、他のブラウザーを試す理由に関するアンケート画面の表示も確認されている (Neowin の記事)。

アンケート画面は「アクション センター」サイドバーに表示され、「Google 検索が簡単に実行できない」「Google ドキュメントにアクセスできない」「お気に入りやパスワードが保存されていない」「広告やポップアップが多すぎる」「ニュースフィードが気に入らない」「遅すぎる」「ウェブサイトが Microsoft Edge で動作しない」といった選択肢が提示されるという。

Microsoft Edge では Chrome のダウンロードページで通知機能によるポップアップやページ上部に挿入したバナーなどを用い、他のブラウザーをダウンロードする必要がないと宣伝する。アンケートはこういった宣伝とほど押しつけがましいものではなく、Microsoft Edge に対するユーザーの不満点を既に把握して確認しようとしているようにもみえる。ただし、アンケートは Chrome のダウンロード時に必ず表示されるわけではなく、手元の環境では表示が確認できなかった。Neowin の記事では人気投票機能のテストである可能性も指摘している。このアンケート、スラドの皆さんは目撃しただろうか。

headless 曰く、

Google が WebP コーデック (libwebp) のヒープバッファーフロー脆弱性を 9 月 22 日に CVE へ報告したが、CVE-2023-4863 と重複するとして数日後に却下された (CVE-2023-5129)。

この脆弱性は libwebp を使用する多数のアプリに影響するものの、Google は CVE-2023-4863 を Google Chrome における WebP の脆弱性として報告した (Internet Archive のスナップショット)。Google はプラットフォームによって WebP の実装が異なるため、Chromium 以外の製品への脆弱性の影響を判断できないなどと説明したが、他の製品が影響を受けないような印象を与えると批判を受けた。

そのため、CVE-2023-5129 は CVE-2023-4863 と同じ脆弱性を libwebp の脆弱性として報告するもので、詳細な動作の説明が添えられていた (Internet Archive のスナップショット)。しかし、CVE では 2 件を重複するものと判断して CVE-2023-5129 を削除。CVE-2023-4863 側は対象に libwebp を追加するのにとどまり、詳細な説明は参照できなくなっている。

あるAnonymous Coward 曰く、

ネットワークディスプレイ機能を、GNOMEに統合する作業が行われている（ OMG! Linux）。Miracastと、Chromecastに対応予定。クイック設定にあるネットワークディスプレイのアイコンをクリックすると、接続できるディスプレイが表示され、その中から選んで接続できる。プレゼンなどに便利。現在でも、GNOME Network Displays というアプリでMiracastを使うことができるが、これがGNOMEに統合されるということだ。

これは、Google Summer of Codeのプロジェクトの一つである。Google Summer of Codeは、学生がメンテナーのサポートを受けながら、OSSの開発をすることができるというものだ。GNOMEの他にも、Gentoo、openSUSE、NetBSD、FreeBSD、X.Org、GNU、KDE、QEMU、Chromium、Tor、VideoLAN、Inkscape、GIMP、Blender、Postman、Django、GitLab、Git、Jenkins、Swift、Kotlin、R、Ruby、Dart、Python、Creative Commons、OpenStreetMap、Wikimedia、Internet Archive、The Linux Foundation、など計168ものOSSプロジェクトが参加している。

来年、Google Summer of Code に参加してみようかな。

Microsoft Edge Canary で EPUB 形式電子書籍サポートが復活している (Microsoft Community Hub の記事、 Neowin の記事、 BetaNews の記事)。

Windows 10 Creators Update 以降のレガシー Edge では EPUB がサポートされていたが、Chromium Edge リリースに伴ってサポートが終了していた。Edge Canary ではバージョン 117.0.1989.0 以降で EPUB サポート機能が追加されており、コマンドラインオプション「--enable-features=msEdgeEpubReaderEnabled」を付加して起動することで有効になる。レジストリを編集すれば EPUB ファイルを Edge Canary に関連付けて開くことも可能だ。GitHub の MSEdgeFeatures リポジトリでは EPUB を有効にして Edge Canary を起動するバッチファイルの生成スクリプトも公開されている。

EPUB サポートを有効にすると Edge Canary の設定画面で「Cookie とサイトのアクセス許可」に「EPUB documents」が追加され、オプション「Always download EPUB filed」で EPUB ファイルを開くか、ダウンロードするかを指定できるようになる。ただし、このオプションをオンにするとダウンロード後のファイルを含めて EPUB ファイルは常にダウンロードされ、Edge Canary での閲覧はできなくなる。

現在のところ、Edge Canary の EPUB サポートは基本的な表示機能のみで、レガシー Edge に搭載されていたようなライブラリー機能は利用できない。コレクションに追加することは可能だが、ダウンロード済みファイルには対応しない。音声読み上げ機能も動作しないようだ。

Mozillaは4日、デスクトップ向けのウェブブラウザ「Firefox」の最新バージョンである「Firefox 115.0」をリリースした。このアップデートは、「Firefox 102」以来の節目となるアップデートとされ、長期サポート版「Firefox ESR」やメールソフト「Thunderbird」も将来的にこのバージョンに移行される予定。Windows 7/8.xおよびmacOS 10.12〜10.14に対応する最後のバージョンとなる（Mozilla、窓の杜）。

主要な変更点としては、「Chromium」ベースのWebブラウザーで保存した支払い方法を「Firefox」に引き継げるようにしたこと、Linux環境でIntel GPUを用いたハードウェアビデオデコーディングが有効に。タブマネージャのドロップダウンに閉じるボタンが追加。他のWebブラウザーからデータをインポートするためのユーザーインターフェイスを刷新。H264ビデオデコードがプラットフォームでサポートされていない場合、CiscoのOpenH264プラグインにフォールバックして再生できるようになるといった変更が加えられている。

Google は数週間前に Windows 11 バージョン 22H2 上の Chrome Canary でマイカ効果をタイトルバー (タブバー) に適用したが、現在ではフラグでの有効化が必要になっている (Gerrit Code Review 4552330、 Neowin の記事)。

Microsoft がパフォーマンスへの影響が小さいと説明するマイカ効果だが、Chromium チームは電力消費に不満があるようだ。そのため、デフォルト有効で幅広く展開する前にさらなる最適化が必要とのこと。

マイカ効果の適用を指定するフラグは chrome://flags の「Windows 11 Mica titlebar (chrome://flags/#windows11-mica-titlebar)」で、「Enable」にして Chrome を再起動すれば有効になる。

なお、マイカ効果の適用対象がタイトルバーだけなのであまり目立たず、「タイトルバーとウィンドウの境界線」にアクセントカラーを表示するオプションが有効の状態では効果が見えなくなる。

Google が Chrome の HTTPS 接続時に表示するアイコンを現在の「ロック」アイコンよりもセキュア感を与えにくい「チューン」アイコンへ変更する計画を示している (Chromium Blog の記事、 Neowin の記事、 The Register の記事、 Android Police の記事)。

ウェブブラウザーでは Netscape の初期のバージョンから HTTPS 接続時に南京錠をデザインした「ロック」アイコンが表示されてきたが、ほとんどの接続が HTTPS となった現在では誤ったセキュア感を与える表示との見方もある。以前は多くのブラウザーがロックアイコンとともに表示していた「保護された通信」のようなテキストは廃止されたが、今でもロックアイコンをサイトを信頼できるかどうかの基準にしているユーザーは多いようだ。

Google は Chrome 93 でロックアイコンをよりニュートラルなドロップダウンボタンのような表示に置き換える実験をしており、スライダーを並べたようなデザインの「チューン」アイコンもこれを踏襲したものになる。選定理由としては、コントロールや設定を示すアイコンであり、クリックして使用するコントロールだとわかりやすいことや、信頼性の高さを示唆しないことが挙げられている。

新しいアイコンは 9 月リリースの Chrome 117 で投入予定だ。Chrome Canary では chrome://flags で「Chrome Refresh 2023 (chrome://flags#chrome-refresh-2023)」を Enabled にすることで新しいアイコンの表示を試すことができる。ただし、新しい表示は開発途中のものであり、最終版とは異なる可能性があるとのことだ。

色覚障害がある人でも見やすいようにした救急車が開発されたそうだ。緊急車両の開発を手がけるベルリングが制作したもので、従来の救急車は、赤が見えにくい人には通常のワゴン車と見分けが難しいという問題があった（共同通信）。

救急車の車体は法令で白と決まっていることから、今回の車両では青を基調としたものとなった。このためタレコミにもあるように救急車には見えないが、見慣れない配色で目立たせ、道を譲ってもらいやすくする狙いがあるという。今回の車両は啓発イベントでの活用や、緊急性の低い患者移送を担う民間救急での導入を目指すとしている。

あるAnonymous Coward 曰く、

デモ車の塗装パターンは最早都市迷彩と言って良い位で駄目でしょう。
もう少し幾何学的にする必要がある。
当然数10年かけて徐々に移行していかないと、タレコミ子には救急車には見えない。
そーいえば外国では緊急車両の回転灯に、青光を採用する事が多かったな。

headless 曰く、

Google が Chrome 拡張の Manifest V2 (MV2) から Manifest V3 (MV3) への移行計画を再び先送りするようだ (Google グループ — Chrome Extensions、 Ghacks の記事)。

Google は 2018 年に MV3 を発表し、当初は 2023 年 6 月に MV2 サポートを完全終息する計画だった。しかし、MV3 の API 実装や最も影響を受けるコンテンツブロッカーの MV3 移行は進んでおらず、昨年 9 月には MV2 終息の半年先送りを発表している。12 月に更新された MV2 サポートタイムラインでは MV2 無効化実験開始や MV2 エンタープライズポリシー終了などが「検討中」に変更され、2023 年 3 月までに新しいスケジュールを発表する計画を示していた。

今回 Google は MV3 の API 実装や改良が進んだとしつつ、MV2 のフェーズアウトに関してはタイムラインの検討を続けているとして、新たなスケジュールを今後数か月のうちに発表する計画を示した。Google では開発者が十分な移行時間をとれるよう、MV2 無効化実験を開始する少なくとも 6 か月前には情報を提供したいとも述べている。

Yandex のエンジニアが Yandex Browser のパフォーマンスと安定性の問題を調べていたところ、AMD の GPU ドライバーの挙動がブラウザーの実行ファイル名によって変わることを発見したそうだ (Neowin の記事、 Habr の記事)。

発見のきっかけとなったのは、Lenovo のノート PC に搭載されたタッチパッドでウェブページをスクロールする際、Yandex Browser ではひどくカクカクした動作になるのに対し、Google Chrome や Microsoft Edge では滑らかな動作がみられたことだ。Chrome も Yandex も Chromium ベースであり、タッチパッドイベントの処理もオープンソースの Chromium と違いはみられないという。そのため、何か他の部分に問題があると考えて調査を進め、実行ファイル名を「browser.exe」から「chrome.exe」に変えると問題が解消することを発見する。

ゲームアプリでは実行ファイル名によって GPU ドライバーが最適化を行うことが知られているが、Yandex は AMD の GPU ドライバーがブラウザーアプリでも実行ファイル名によって最適化を行うという仮説を立てて実験。Chromium のサンドボックス機能を利用して「GetModuleFilenameA/GetModuleFilenameW」関数と「GetModuleFilenameExA/GetModuleFilenameExW」関数が返す実行ファイル名をbrowser.exe」から「chrome.exe」に変更してテストを実行したところ、GPU プロセスのクラッシュ回数は 5.5 分の 1 に減り、メモリ使用量は 8% 減少したという。ウェブページの読み込みやユーザーインターフェイスの反応もわずかに向上したそうだ。

この結果を受けて Yandex は AMD に「browser.exe」を最適化対象の実行ファイル名リストに加えるよう要請する一方、Windows 版の Yandex Browser バージョン 22.9.0 以降では GPU プロセスで「chrome.exe」のふりをするよう変更したとのことだ。

Microsoft Edge が Google Chrome のダウンロードページに大きなバナーを表示して、移行を阻止しようとする現象が確認されたそうだ (Neowin の記事、 9to5Google の記事、 Softpedia の記事)。

Microsoft Edge で Chrome を Bing 検索すると検索結果の上に「新しい Web ブラウザーをダウンロードする必要はありません。」と表示される。Chrome のダウンロードページでは Edge の使用継続を推奨するバルーンメッセージの表示もこれまでに確認されている。しかし、Neowin によると、Chrome のダウンロードページ上部にウィンドウの横幅いっぱいのバナーが追加され、先述のバルーンメッセージと同様の内容のメッセージが表示されたそうだ。

Neowin は Microsoft Edge Insider チャネルのビルドでのみ表示を確認しており、安定版では表示されなかったと説明しているが、9to5Google の記事では安定版の Microsoft Edge でも表示されたとのコメントもみられる。その後、Neowin の記事にはベータチャネル以外で表示されなくなったと追記された。ただし、手元の環境ではベータチャネルでも表示されなかった。スラドの皆さんはこのようなバナーを目にしただろうか。

Windows 7 の拡張セキュリティ更新プログラム (ESU) 提供と Windows 8.1 の延長サポートが 1 月で終了したが、これが Mozilla にとって大きなチャンスだと BetaNews が主張している (BetaNews の記事)。

デスクトップ版ウェブブラウザーでは Google Chrome が圧倒的なシェアを占めている。StatCounter のデータによれば、1 年ほど前まで Microsoft Edge と Apple Safari、Mozilla Firefox が第 2 グループを構成していたが、最近では Edge が頭一つ抜け、Firefox は Opera と Edge の中間ぐらいのシェアに落ち込んでいる。

Microsoft による Windows 7 / 8.1 のサポート完全終了に伴い、今月提供が始まった Chrome 110 と Edge 110 でも Windows 7 / 8.1 がサポートされなくなっている。一方、Mozilla では 3 年以上前からサポート終了時期を検討しており、Firefox の Windows 7 ユーザーが多いことからサポートを延長する方向に傾いている。

現在のところいつまで延長するのか明確には示されていないが、Firefox Nightly 111.0a1 でも OS 要件は Windows 7 以降となっている。Mozilla の Romain Testard 氏によれば、ESR 115 よりも前にサポートを終了することはないと考えていいだろうとのこと。

BetaNews は StatCounter の Windows シェアデータで 12 % 以上を占める Windows 7 ~ 8.1 のユーザーを Chrome と Edge が失うことになるとして、Firefox やその他の小さなブラウザーメーカーが受け皿になることでユーザーを獲得できると主張する。ただし、古いバージョンの Windows をサポートすることで獲得したユーザーはいつまでも保持できるわけではない。

なお、Brave は既に Chromium 110 ベースとなっており、今後のアップデートには Windows 10 以降が必要と表示される。一方、Opera (Chromium 109 ベース) や Vivaldi (Chromium 108 ベース)は現在のところ Windows バージョンに関する警告を表示しない。

headless 曰く、

Google Chrome で保存先に共有フォルダーやクラウドドライブを指定するとエラーメッセージが表示され、ファイルをダウンロードできないという問題が発生しているそうだ (Issue 1408321、 The Register の記事)。

エラーメッセージは「このファイルを開けません / システムファイルが含まれているため はこのフォルダのファイルを開くことができません」というもので、別の場所を指定しない限り保存できない。showOpenFilePicker API で UNC パスのファイルを選択した場合にも同じ問題が発生する。

問題が報告されたのは 32 ビット Windows 版の Chrome 109.0.5414.94 で、手元の 64 ビット Windows 版 Chrome 109.0.5414.120 では showOpenFilePicker API の問題は確認できたが、ファイルの保存は特に問題なかった。同 API の問題は The Register が macOS 上の Chrome 109.0.5414.119 (arm64) でも確認している。

Google はこの問題を M110 ブランチで修正する計画とのことだ。