ブラウザの更新情報というと新しいCSSやAPIに目が向きがちですが、9月に出たChrome 154とFirefox 155、156の開発者向けリリースノートを読み比べると、こちらが何も変えていなくても既存サイトの見え方や動き方に関わる変更がいくつか含まれていました。新機能の紹介とは少し角度を変えて、納品済みのサイトや社内システムを抱える側が気にしておきたい項目を並べてみます。

その1 HTTPのまま開くと確認画面が出るのが既定に

Chrome 154では、暗号化されていないhttpの接続でサイトを開こうとしたとき、利用者に確認を求める動作が既定で有効になりました。管理者向けには企業ポリシーでこの既定を制御する手段も用意されています。

公開サイトの多くはすでにHTTPS化されていますが、気になるのは周辺部分です。印刷物やQRコードに載せたhttpのURL、古い記事の中に残った内部リンク、LAN内で動く機器の管理画面などは、これまで素通りだったところで一度立ち止まる形になります。httpからhttpsへの転送がきちんと効いているか、紙の販促物に刷ったURLが今どうなっているかを、この機会に確かめておくと安心です。

その2 古い鍵交換方式だけのサーバーにFirefoxがつながらなくなる

Firefox 156では、TLSの接続開始時に既定で提示する鍵交換の方式から、有限体Diffie-Hellmanのffdhe2048とffdhe3072が外れました。リリースノートによると、これらの方式しか扱えないサーバーとは接続の取り決めが成立しなくなるとされています。

ほとんどのサーバーは楕円曲線を使うECDHEに対応しているため、一般的なレンタルサーバーやCDN経由のサイトで問題になることはまずないはずです。ただ、長く更新されていない自前のサーバー、古い業務用機器の管理画面、社内の古いシステムなどはこの限りではありません。「Firefoxでだけ開けない」という問い合わせが来たときの確認項目として覚えておくと役に立ちます。

その3 ポップオーバーやダイアログが意図せず閉じにくくなった

Chrome 154では、ポップオーバーやダイアログの外側を押したときに閉じる「ライトディスミス」の判定が、押し下げと離す操作の組み合わせからクリックイベントに切り替わりました。これにより、スマートフォンで画面をスクロールしただけのときや右クリックしたときに、開いていたメニューが勝手に閉じてしまう現象が起きにくくなります。

利用者にとっては素直な改善ですが、標準のpopover属性やdialog要素の挙動に合わせて独自の処理を足しているサイトでは、閉じるタイミングが以前と少しずれる可能性があります。スマートフォンでメニューを開いたまま縦にスクロールしてみる、といった簡単な確認をしておくとよさそうです。

その4 読み込みに失敗したモジュールを後から読み直せる

Firefox 155では、ネットワークエラーやMIMEタイプの誤りで読み込みに失敗したJavaScriptのモジュールが、失敗した状態のまま記憶されなくなりました。サーバー側が復旧すれば、同じ指定で読み込み直したときに成功するようになります。JSONやCSSのモジュール、動的なimportも対象です。

サーバーの一時的な不調やデプロイ中の瞬断で、ページを開き直すまで一部の機能が動かないという状況が減る方向の変更です。逆に言えば、配信側でMIMEタイプの設定を誤っていた場合、再試行のたびに同じ失敗を繰り返すことになるので、サーバー設定の見直しは引き続き大切です。

その5 開発者ツールの表示サイズが端数まで出るように

Firefox 156の開発者ツールでは、インスペクターで要素を選んだときに出るビューポートの幅と高さが、四捨五入されずに表示されるようになりました。ブラウザの拡大率が中途半端なときや高精細なディスプレイでは、これまでの表示が実際と食い違っていたためです。

レスポンシブデザインの切り替え幅を確かめる際、境界ぎりぎりで表示が崩れる原因を追うときに小数点以下の値が見えるのは助かります。制作中に表示される数字が以前と違って見えても、不具合ではなく正確になった結果と受け止めてよいでしょう。

どれも派手な変更ではありませんが、何年も前に納品したサイトほど影響を受けやすい種類の話です。隔週で更新が届く時代になり、こうした細かな挙動の変化は今後も積み重なっていきます。新機能を追いかけるのと同じくらい、既存のサイトに何が起きうるかを定期的に拾っておくことが、運用を任される側の地道な仕事になりそうです。