公開2026.09.02更新2026.10.12 ブラウザ

Firefox 155の開発者向け変更点｜今すぐ使える機能と既存サイトが壊れる3点

Firefox 155 が 2026年9月1日に stable チャネルへ公開されました。CSS では attr() の型指定が既定で有効になり、progress() と alpha() が加わりました。ただし「Firefox が対応した」ことと「本番のコードに書ける」ことは別で、判断は他ブラウザの実装状況を突き合わせないと決まりません。同時に mailto: の発火条件、ポータル検知ドメイン、CSS ネストの深さ上限という3つの引き算も入っています。MDN のリリースノートと browser-compat-data を一次情報として、書き換えてよい機能と回帰確認が要る箇所を切り分けます。

まとめ：Firefox 155で書き換えていい機能と回帰確認が要る3点

155 の CSS 追加のうち、この版をもって主要4ブラウザが揃うのは progress() と alpha() です。Chrome と Edge は 138 と 151、Safari は 26 と 27 で先に入っており、Firefox が最後の穴でした。逆に attr() の型指定は Safari が未対応のまま残るため、本番のレイアウト計算には使えません。font-width は Chrome と Edge が未対応で、実務では font-stretch を書き続けます。

JavaScript 側の Promise.allKeyed() は MDN が experimental と明示する段階で、本番投入は見送りになります。回帰確認が要るのは3点。location.href にメールリンクを代入する実装、CSS ネストが 75 段を超えるビルド生成物、社内プロキシの許可リストにポータル検知ドメインを直書きしている環境です。自動テストを回している組織はもう1点、WebDriver BiDi の session.unsubscribe が contexts 引数を受け付けなくなった変更を確認してください。

Firefox 155のリリース日とチャネル構成｜155・156・ESRの更新間隔

2026年9月1日のstable公開と修正済み脆弱性32件の内訳

Firefox 155.0 の stable 公開日は 2026年9月1日。同日付でセキュリティアドバイザリ mfsa2026-82 が出ており、2026年9月2日時点の掲載では 32件の脆弱性が修正されています。内訳は High 15件・Moderate 9件・Low 8件。High には DOM: Navigation と DOM: Security のサンドボックス脱出、Graphics: WebGPU の権限昇格といった use-after-free 系が並びます。

サンドボックス脱出を含む更新を機能検証のために止めて得られるのは、後述の回帰3点を確認する時間だけ。回帰3点は自社サイト側のコードを見れば判定できるので、端末への配信は先に流し、サイト側の確認を並行させるほうが実務的でしょう。

次版156までの2週間と140系・153系ESRの併走スケジュール

Firefox のリリースカレンダーでは 156 が 2026年9月15日、157 が 9月29日。155 が現行でいられる期間は2週間しかありません。ESR は 140系と153系が併走し、156 公開のタイミングで 140.16 と 153.3 が出る計画で、カレンダー上には 115系も併記されています。

2週間ごとに前提が動くため、155 固有の挙動に依存した暫定対応を長く抱えると総コストが上がります。一般利用者向けの更新手順、ESR と通常版の違い、版数の履歴はFirefoxの最新版と更新方法・ESRの違いの総まとめで扱っているため、以降は 155 の差分だけを追います。

CSSのattr()拡張とprogress()｜JS不要のスタイル制御と対応ブラウザ

155 の CSS 追加は4つ。機能ごとにクロスブラウザまでの距離が違うため、まず対応表で位置を確かめます。数値は 2026年9月2日時点の MDN browser-compat-data による実測値です。

機能	Firefox	Chrome・Edge	Safari	本番投入
attr()の型指定	155で既定有効	133	未対応	見送り
progress()	155	138	26	可
alpha()	155	151	27	可
font-width	155	未対応	18.4	別名を継続

attr()がcontent以外で使える条件とSafari未対応の制約

従来の attr() は content プロパティ専用でした。155 では単位識別子付きの型指定が既定で有効になり、width: attr(data-size px) のように任意のプロパティへ属性値を流し込めます。フォールバック値と名前空間付き属性も通ります。Firefox 149（2026年3月24日）でフラグ付き実装が入り、155 でリリース既定に切り替わった流れです。

それでも本番では書けません。Chrome と Edge は 133（2025年2月）で対応済みの一方、Safari は 2026年9月2日時点で型指定に未対応。<length> も <color> も落ちるため、属性値でカードの幅やバッジ色を決めると Safari だけ崩れます。使えるのは、崩れても意味が通る装飾に限った段階的強化まで。寸法計算は従来手法を続けてください。

progress()で書ける流体タイポグラフィとcalc()併用の例

progress() は開始値と終了値のあいだで現在値がどこにあるかを 0 から 1 の数値で返す関数です。opacity: calc(0.4 + progress(100cqw, 300px, 900px) * 0.6) と書けば、コンテナ幅 300px から 900px の区間で不透明度が 0.4 から 1.0 へ線形に動きます。効くのは流体タイポグラフィとビューポート連動の余白。clamp() の入れ子で可読性を落としていた計算が1行になります。

本番投入の条件は 155 で揃いました。Chrome 138（2025年6月24日）、Edge 138（同6月26日）、Safari 26（2025年9月15日）に続いて Firefox が入ったためです。MDN の Baseline 表示が 2026年9月2日時点でまだ Limited availability なのは判定データが版の公開に遅れるからで、実装は横並びと見てよいでしょう。

alpha()による透明度派生とfont-widthへの改名の扱い

alpha() は既存の色を受け取り、アルファ値だけ差し替えた色を返します。alpha(from var(--brand) / calc(alpha * 0.5)) のように書き、ブランド色を1か所で定義したまま半透明の派生色を作れます。対応は Chrome 151・Edge 151・Safari 27・Firefox 155 で、これも 155 で横並びに。透明度違いの色変数を人手で並べる運用をやめられます。

font-width は別種の変更です。font-stretch の新しい名前として導入され、@font-face のディスクリプタと CSSStyleDeclaration.fontWidth も実装されました。ただし Chrome と Edge は未対応、Safari は 18.4（2025年3月31日）で先行済み。旧名は別名として動き続けるため、書き換える実利がありません。可変フォントの幅軸の指定は触らないでおきます。

JS APIの投入判断｜Promise.allKeyedとWebTransportの拡張

Promise.allKeyedが解く並列awaitの取り違えと投入可否

Promise.allKeyed() と Promise.allSettledKeyed() は、Promise を値に持つオブジェクトを受け取り、結果を位置ではなく名前で返します。Promise.all([a, b, c]) の戻り値を配列分割で受けるコードは、並べ替えのたびに取り違えが起きます。名前で受け取れれば、その事故が構造的に消える理屈です。

それでも 155 では書けません。MDN のリファレンスは experimental の警告を出し、仕様は TC39 の Await Dictionary 提案、browser-compat-data には項目自体がまだありません。単一ブラウザの先行実装を入れると他ブラウザで機能ごと落ちます。同じ効果は Object.fromEntries() と Promise.all() の自前ヘルパーで得られます。

WebTransport送信グループと鍵材料エクスポートの用途

WebTransport への追加は5点あり、重心は帯域制御にあります。createSendGroup() で作った WebTransportSendGroup をストリーム作成時に渡すと、グループ単位で帯域を分け合い優先度を付けられます。コンストラクタの protocols オプションでプロトコルを提示でき、サーバーが選んだ値は protocol プロパティから読み取れる形。停止要求は draining プロパティで観測します。

exportKeyingMaterial() は TLS 接続から派生鍵材料を取り出す API で、想定用途はアプリケーション層のハンドシェイクでの中間者検知です。WebTransport を使う構成はサーバーも自社で持つケースが多く、対象ブラウザを社内端末に絞れるなら 155 前提で組んでも実害は出ません。

モジュール読み込み失敗時のキャッシュ廃止と再取得での復旧挙動

地味ですが運用に効く修正が入りました。155 以前は、ネットワークエラーや誤った MIME タイプで読み込みが失敗すると、その失敗がキャッシュされ、サーバーが復旧しても同じ URL の再 import が失敗し続けました。155 ではこの失敗をキャッシュせず、JavaScript・JSON・CSS・テキストの各モジュールで、静的と動的の両方の import が対象になります。<link rel="modulepreload"> も挙動が揃い、取得済みまたは取得中のモジュールでは error ではなく load イベントが発火します。

デプロイ直後に CDN のキャッシュが温まりきらず一部チャンクが 404 を返す構成では、これまでリロードでしか復旧しませんでした。動的 import のリトライを自前で書いた箇所は、遅延の値を見直せます。なお同じ 155 では SVGTransformList のインデックス代入、getBBox() の options 引数、WebGPU の dual-source-blending、WebAssembly の幅広演算命令も入りましたが、影響は描画・計算ライブラリ側に限られます。

接続の高速化｜Happy Eyeballs v3とQUIC version 2の実務影響

Happy Eyeballs v3のIPv6競走と一部プラットフォーム限定の注意

Happy Eyeballs v3 は、IPv6 と IPv4 のアドレスへ同時に接続を試みて先に確立したほうを採る仕組みです。IPv6 の経路が張られているのに応答が遅い環境では、従来はタイムアウトを待って IPv4 へ落ちていました。その待ち時間が消え、初回接続の遅延が縮みます。

ただし 155 の実装は一部プラットフォーム限定で、全環境が同じ挙動になるとは限りません。注意点は計測のほう。デュアルスタック環境で表示速度を追っている場合、155 前後で接続確立時間が変わるため、155 の到達日を計測ログに注記しておくと後から切り分けられます。

QUIC version 2交渉とHTTP/3運用側で確認する設定

155 は HTTP/3 接続で QUIC version 2 をネゴシエートできるようになりました。version 1 との違いはパケットの版数フィールドや暗号化に使う定数の値で、機能そのものは変わりません。狙いは、経路上の中継機器が version 1 だけを前提に固定化してしまう状態を避けることです。仕組みの前提はQUICとHTTP/3の仕組みとTCPとの違いで整理しています。

サイト側の作業は基本的に不要。確認したいのは、CDN や自前のリバースプロキシで QUIC の版を絞る設定を入れていないかどうかです。version 1 のみ許可が残っていると 155 は交渉に失敗して HTTP/2 へ落ちます。

DevToolsの更新｜メディア特性エミュレーション統合とJSON Lines対応

メディア特性エミュレーションの集約とprefers-reduced-motion検証

ルールビューに散っていたメディア特性のエミュレーションボタンが、アットマークのボタンで開く専用パネルに集約されました。あわせて prefers-reduced-motion のエミュレーションが加わり、OS 設定を切り替えずにアニメーション抑制時の表示を確認できます。デバッガーには全ブレークポイントを一括で無効化するショートカットも追加。

効くのはアクセシビリティ検証の工程です。prefers-reduced-motion は WCAG 2.1 の 2.3.3 と 2.2.2 に関わる分岐で、これまでは OS の設定画面を往復していました。ただし手元の確認と達成基準に沿った試験は別物。対象範囲と適合レベルを決めて進める段階では、Webアクセシビリティ対応の支援のような診断・改修の工程と組み合わせるのが確実でしょう。

JSON Lines対応で変わるログ確認とMIMEタイプ4種の扱い

JSON ビューアが JSON Lines 形式に対応しました。認識されるのは application/jsonlines、application/x-ndjson、text/jsonl の各 MIME タイプと、拡張子 .jsonl の4通り。各行が個別の折りたためるエントリとして解析され、途中の行でパースに失敗してもその行だけがインラインで報告されます。

従来はブラウザで開いても1行ずつのテキストが並ぶだけで、フィールドを見るにはエディタへ移す手間がありました。ログ配信のエンドポイントや一括書き出し API を直接叩いて中身を確認する運用が、そのまま成立します。

既存サイトが壊れる3変更｜mailto:制限・CSSネスト75段・検知ドメイン変更

ここが 155 で唯一、締め切りのある作業です。3点はいずれも引き算で、該当すれば動かなくなります。自社の該当有無を先に判定してください。

mailto:のユーザー操作限定でJSの自動遷移が止まる実装箇所

mailto: リンクの実行が、ユーザー操作を伴う場合に限定されました。クリックやキー入力から始まった処理でしか送信画面が開きません。該当するのは、フォーム送信の完了後に location.href へ mailto: を代入する実装、タイマーやポーリングの結果として自動でメール作成画面を出す実装、確認ダイアログを自前で挟んだ結果クリックとの因果が切れている実装です。

お問い合わせ完了画面から担当者宛のメーラーを自動で開く動線は、この変更で無反応になります。直し方は単純で、自動遷移をやめて mailto: の a 要素を画面に出すこと。メーラー起動を前提にした業務フローは、送信フォーム経由へ寄せるほうが後々の互換性で有利です。

CSSネストの75段上限とビルド生成物で上限を超えるプリプロセッサ構成

155 では CSS のネストされたブロックと関数の深さが 75 段に制限されました。安定性のための上限で、手書きの CSS がこの深さに達することはまずありません。問題は生成物のほうです。

Sass や Less のミックスインが再帰的に展開される構成では、生成後の CSS が想定外の深さになることがあります。判定は簡単で、ビルド後の CSS を Firefox 155 で読み込み、スタイルエディタに解析エラーが出るかを見るだけ。上限超過箇所は無視されるので、ページ全体が崩れるのではなく特定の指定だけが効かない症状で出ます。

ポータル検知ドメインの変更と社内プロキシ許可リストへの追加値

キャプティブポータルの検知に使うドメインが detectportal.firefox.com から firefox-portal-detection.com へ変わりました。ブラウザが接続状態を判定するために叩く先で、サイト側のコードとは無関係。効くのは社内ネットワークの設定です。

プロキシの許可リストやファイアウォールのポリシーに旧ドメインを直書きしている環境では、新ドメインへの通信が落ちます。症状は接続判定が通らないことによる警告表示や確認待ちで、ブラウザ本体の不具合と見分けづらい。情報システム部門への依頼は「許可リストに新ドメインを追加し、旧ドメインは移行完了まで残す」の1行で足ります。

WebDriver BiDiの仕様変更｜E2Eテストが失敗する条件と修正手順

自動テストを回している組織にとって、155 で最も影響が大きいのはここ。CI が赤くなる形で現れます。

session.unsubscribeのcontexts引数廃止で落ちるテスト

session.unsubscribe コマンドが contexts 引数のサポートをやめました。155 以降は、イベント名または購読 ID を指定した解除だけが通り、「この文脈のこのイベントだけ購読を外す」という呼び出しは受け付けられません。

該当するのは、WebDriver BiDi を直接叩く自前のクライアントと、低レベル API で購読管理を自分で書いているコードです。多くの自動テストは高レベル API しか触らないため無関係ですが、ネットワークイベントを文脈単位で購読・解除している実装は落ちます。ブラウザを外部から操作する仕組みの前提はSelenium 4でのWebDriverの扱いで整理しています。

購読IDでの解除に書き換える手順と自動テストツールの追随状況

直し方は、購読時に返る ID を保持する形へ寄せることです。手順は3つになります。

session.subscribe の戻り値にある購読 ID を変数へ保存する
解除は contexts ではなく、その購読 ID を渡して呼ぶ
文脈ごとに解除したい場合は、購読自体を文脈ごとに分けて発行しておく

3番目が設計の変更点で、購読の粒度をあらかじめ分ける必要があります。ドライバやテストライブラリがどの BiDi コマンドを呼ぶかは版によって変わるため、CI のブラウザを 155 へ上げる前に、購読解除を含むテストだけ先に単独で走らせるのが安全な順序でしょう。

DevToolsとBiDiの併用競合の解消とreloadの不具合修正

同じ 155 では BiDi 側の不具合修正も入りました。moz:debugging モジュールが DevTools と同じ入れ子イベントループ API に依存しなくなり、BiDi と DevTools の同時使用時の競合が避けられます。browsingContext.reload がフレームを含むページで失敗する不具合も直りました。

あわせてダウンロード開始時にドキュメントがフォーカスを失わなくなり、非 macOS 環境で Ctrl を伴うダブルクリックが dblclick イベントを発火します。フォーカス依存のアサーションで不安定だったテストは 155 で結果が変わるため、安定化のために入れた待機処理が不要になっていないかを見直してください。

よくある質問

Firefox 155 について、実装と運用の現場から確認されることの多い5点です。

Firefox 155はいつリリースされましたか？

stable チャネルへの公開は 2026年9月1日です。同日付のセキュリティアドバイザリ mfsa2026-82 では、2026年9月2日時点の掲載で 32件の脆弱性が修正されています。次版の 156 は 2026年9月15日、157 は 9月29日がリリース予定日で、更新間隔は2週間です。

Firefox 155のバージョンはどこで確認できますか？

アドレスバーに about:support と入力すると、アプリケーション基本情報の欄にビルド番号を含む版数が表示されます。メニューからヘルプの Firefox についてを開く方法でも版数が分かり、その画面を開いた時点で更新の確認が走ります。企業の管理端末では配信が保留されている場合があるため、端末の表示だけで判断しないでください。

Firefox 155のCSS attr()拡張は本番で使えますか？

2026年9月2日時点では見送りが妥当です。Chrome と Edge は 133 で型指定に対応済みですが、Safari は未対応のまま残っています。属性値でレイアウトの寸法や色を決める設計にすると、Safari だけ指定が落ちて表示が崩れます。崩れても意味が通る装飾に限った段階的強化なら書けるでしょう。データ由来の値をスタイルへ渡すなら、HTML 側で CSS カスタムプロパティを出力する従来手法が安全です。

Firefox 155で既存サイトが動かなくなる変更はありますか？

3点あります。1つ目は mailto: の実行がユーザー操作を伴う場合に限定された変更で、JavaScript から自動でメーラーを開く実装が止まります。2つ目は CSS のネスト深度の 75 段制限で、プリプロセッサの生成物が深い構成では一部の指定が無視されるでしょう。3つ目はポータル検知ドメインの変更で、社内プロキシの許可リストに旧ドメインを直書きした環境が影響を受けます。

Firefox 155のESR版はどのバージョンになりますか？

155 に対応する ESR は提供されません。ESR は特定の版を長期保守する枠で、2026年9月2日時点では 140系と 153系が現行として併走し、リリースカレンダーには 115系も併記されています。管理端末で版を固定したい場合は ESR チャネルを選ぶことになりますが、155 で入った CSS 関数や WebTransport の拡張は ESR では使えません。