25年越しに修正された Firefox の <textarea> バグ

 (bugzilla.mozilla.org)
1 ポイント 投稿者 GN⁺ 2024-05-23 | 1件のコメント | WhatsAppで共有
  • Firefox の古い Bug 33654 は、<textarea> が ROWS= と COLS= を適用する際にスクロールバーの領域まで加算され、指定した行数・列数より大きく見えていた問題で、現在は Bug 1830576 の重複としてクローズ済み
  • overlay scrollbars が無効、または「always show scrollbars」設定を使う環境で、<textarea rows=N> が概ね N+1 行の高さとして計算される現象が繰り返し発生
  • 初期の議論は、フォントの継承、monospace の強制適用、w と W の平均幅に基づく cols 計算、スクロールバー領域の予約方式にまで広がり、テストケース・パッチ・スクリーンショットが長期にわたって蓄積
  • 実際には rows=1 が 3 行のように見えたり、rows=2 が 3 行分の高さに見えたり、cols=80 で IE と Firefox の折り返し位置が異なったりするなど、フォームレイアウト制御がブラウザごとにずれていた
  • Bug 1830576 が VERIFIED FIXED になったことで、WebKit、Chromium、Firefox の スクロールバー間隔の適用が一貫し、Bug 33654 は RESOLVED DUPLICATE として整理された

Bug 33654 の状態と範囲

  • Bug 33654 は、<textarea> が ROWS= と COLS= を誤って適用し、overlay scrollbars が無効な状態で横・縦の スクロールバー用の追加領域が生じていた不具合
  • 製品とコンポーネントは Core :: Layout: Form Controls で、HTML フォームコントロールのレイアウトと外観、とくに textarea のような要素が対象
  • 現在の状態は RESOLVED DUPLICATE of bug 1830576
    • 重複先である Bug 1830576 のタイトルは Firefox sizes <textarea rows=N> as roughly N+1 rows tall, under an "always show scrollbars" configuration
    • Bug 1830576 の状態は VERIFIED FIXED
  • このバグは 26 年前に登録され、2 年前に RESOLVED DUPLICATE としてクローズされた
  • メタデータにはバージョン Trunk、プラットフォーム x86 / All、種類 defect、優先度 P3、深刻度 S3 が表示されている
  • キーワードは testcase、Whiteboard は [html][behavior]relnote-devel、投票数は 99 と表示
  • 添付ファイルは 17 files, 17 obsolete files と表示され、テストケース・パッチ・スクリーンショットが繰り返し投稿された

最初に明らかになった症状

  • 最初の報告で Andrew McMillan は、ROWS=5 COLS=30 と指定した TEXTAREA の例が、おおよそ ROWS=7 COLS=48 のように表示されると記録した
  • 初期コメントでは、INPUT TYPE=TEXT と TEXTAREA が指定されたフォントを正しく使っていない、またはスクロールバーが表示されても領域が高すぎるといった事例が続いた
  • その後の議論は、textarea のレイアウトが誤った情報を受け取っており、列には 追加領域があり、行は 1 つ多いという方向にまとまっていった
  • スクロールバー用の領域をあらかじめ確保する方式が原因である可能性も、初期から扱われていた

フォント計算と初期パッチ

  • HTML authoring newsgroup の事例では、textarea { font-size: 8pt } と <textarea cols="40" rows="12"> を併用すると、IE は幅を正しくレンダリングする一方、Mozilla は 12pt フォント基準で幅を計算しているように見えた
  • arial フォントを使うテストファイルには、<textarea NAME=system_code wrap=soft rows=5 cols=30 WRAP style="font-family:arial"> が含まれていた
  • Rod は、デフォルトフォントではサイズ計算が正しいため、sizing 自体よりも textarea が 正しいフォントを使っていない問題が核心だと見た
  • Kin は、editor の PlainText フラグが設定されると TextControl のコンテンツ領域に font-family: monospace; を強制適用するコードを発見した
    • このコードを削除すると正しいフォントが使われる
    • しかし NavQuirks モードでは、30 列の textarea 内の 30 文字の文字列が幅のおよそ 2/3 しか占めない問題が残る
    • 原因として、nsFormControlHelper がフォントから w と W の平均幅を求め、列数と掛け合わせ、scrollbar 幅を足して textarea の幅を計算する方式が指摘された
  • Patch to use the correct font. は plain text editor 初期化フラグに eEditorEnableWrapHackMask を追加し、font-family: monospace; の適用を条件付きに制限した
  • このパッチはいったん RESOLVED FIXED と処理されたが、元の報告者が COLS=... は正しくても ROWS=... は依然として誤動作すると知らせたため、再オープンされた

繰り返された再現と重複バグ

  • 重複バグの一覧には、<textarea> が指定行数より 1 行大きく見えたり、rows=1 が 3 行のように見えたりする問題が多数含まれる
    • Bug 46106: Textarea displaying more rows than designated.
    • Bug 116779: <textarea rows=1> shows 3 rows
    • Bug 133342: textarea always rendered with one more row than defined
    • Bug 186271: textareas are 1 row taller than specified
    • Bug 206946: <textarea rows="2"> shows ~3 lines
    • Bug 911226: <TEXTAREA> always rendered one line too tall !
  • Interactive testcase は、rows と cols の値をボタンで変更できる HTML 4.01 Strict 文書で、font tag や variable-width font は使用していなかった
    • 動作結果は、指定値より常に 3 columns 多く、row は通常 1 つ多い
    • rows=1 を要求すると 3 rows が表示される
  • 2002 年の Linux および Win2000 trunk builds では、<textarea cols=40 rows=2></textarea> が 3 rows として表示され、rows=N なら正確に N+1 rows が表示されるという事例が出た
  • W3C HTML 4.01 テストも参考資料として使われ、ROWS 関連テストで問題が明確に見えるというコメントが付いた
  • Windows 2000 と Mozilla 0.9.3 でも、rows=1 の textarea が明らかに 1 row に見えない例が投稿された

スクロールバー領域計算の議論

  • Comment 86 は、textarea のサイズが指定された cols/rows に scrollbar 領域を足した値として計算されると説明した
  • IE と異なり Mozilla は必要なときだけ scrollbar を表示するため、ユーザーがこれを壊れた挙動だと感じているという分析が出た
  • 可能な選択肢として 3 つが提案された
    • textarea のサイズ計算時に scrollbar サイズを加えない
    • IE のように常に scrollbar を表示する
    • 表示する scrollbar だけを含める
  • 3 つ目の選択肢は、サイズが scrollbar の表示有無に依存し、scrollbar の表示有無が再びサイズに依存して循環的だと指摘された
  • Comment 87 は、ROWS と COLS が textarea content のサイズだけを制御し、scrollbar が表示されると textarea が大きくなる方式を 4 つ目の選択肢として提案した
  • その後の実装方針は、scrollbar なしの width/height で reflow して scrollbar が必要かを判断し、必要なら新しい width/height で再度 reflow する方式として議論された

ユーザーに見えた影響

  • rows="2" を指定したのに 3-row 高の textarea が表示されると、入力量を視覚的に案内する意図が曖昧になる
    • ある Web アプリケーションは短い要約文を求め、rows="2" を使って「1 行よりは多いがエッセイではない」入力量を案内していた
    • Firefox と IE6、Opera 8 の挙動差により、同じ rows 値がユーザーエージェントごとに異なる視覚的案内を生んだ
  • textarea の内容がスクロールされない場合でも、Firefox の挙動は誤っているというコメントが続いた
    • 住所入力のようにほとんど 3 行を超えない textarea に rows="3" を指定しても、Firefox は常に extra row を表示する
    • ページが不必要に大きくなり、ユーザーがボックスが想定より大きいため情報を十分に入力していないと思う可能性がある
  • cols=80 の比較では、IE は 80 個の 1 を scrollbar の端まで埋めてから折り返すが、Firefox は 80 個の 1 の後にさらに 2 個分入るスペースがあり、その後 horizontal scrollbar が表示されるというスクリーンショット説明が付いた
  • 2019 年にも問題が残っているというコメントがあり、Discord の Chat bar is a line taller than usual on Firefox Trello カードが影響例として提示された

長期にわたったパッチの試み

  • Hideo Saito は複数回にわたりパッチとテストケースを添付した
    • patch for rows and cols
    • wrap="off" パッチのテストケース
    • base patch
    • additional patch for another bug
    • patch which does not remove space
  • あるアプローチは、nsTextControlFrame::Reflow をスクロールバーを除いた intrinsic size で実行した後、scrollbar があれば intrinsic size に scrollbar サイズを足して再び reflow する流れだった
  • GetScrollbarStyles を修正し、text control frame が scrollbar を auto、hidden、scroll のいずれにするか制御するアプローチも扱われた
  • roc は、nsGfxScrollFrame に多くの変更を入れる方式より、nsTextControlFrame で処理する案を好んだ
  • その後のパッチは、SetScrollbarStyles、GetScrollbarStyles、SetScrollbarSpace、GetScrollbarOverflowState、FrameNeedsReflow、post-reflow callback などのメカニズムをめぐってレビューと再作業を繰り返した
  • 一部のパッチは review- を受けたり obsolete 扱いになったりし、レビュアーは trunk に合わせた更新が必要だと指摘した

一時的な回避策と限界

  • CSS textarea{ overflow-x: hidden } を追加すれば問題が解決するという提案があった
  • この方法は、水平スクロールバーが不要な場合にのみ適用できるという条件付きだった
  • 別のコメントは、このバグは CSS overflow だけでは直せず、Firefox が textarea に 1 行を余分に追加してレンダリングする唯一のブラウザだと反論した
  • Emilio Cobos Álvarez は、原因は scrollbar サイズにあるようで、<textarea> に scrollbar-width: none を適用すると解決するように見えると述べた
  • 同じコメントは、それでもバグ自体は修正されるべきだと付け加えた

最終整理

  • 3 年前、BugBot はこのバグの severity が相対的に低い S3 だが、重複 27 件、投票 103 件、CC 91 件があるとして severity 引き上げの検討を求めた
  • バグの要約は TEXTAREA incorrectly applying ROWS= and COLS= から TEXTAREA incorrectly applying ROWS= and COLS= (horizontal / vertical scrollbar extra space, with overlay scrollbars disabled) に変更された
  • Daniel Holbert が Bug 1830576 Firefox sizes <textarea rows=N> as roughly N+1 rows tall, under an "always show scrollbars" configuration を依存関係に追加した
  • Luke Warlow は、Bug 1830576 が修正されたため WebKit、Chromium、Firefox の スクロールバー間隔の適用が一貫するようになり、このバグを閉じられるか尋ねた
  • Emilio Cobos Álvarez がこれに同意し、Bug 33654 は NEW から RESOLVED に変わり、DUPLICATE としてクローズされた
  • 重複先は Bug 1830576 に指定されており、そのバグは VERIFIED FIXED 状態

関連記事

1件のコメント

 
GN⁺ 2024-05-23
Hacker News の意見

  • は！その25年の大半、このバグを購読していた。当時は Firefox はなく、これは Netscape Navigator ではなく、その前後の Mozilla 側のバグとして登録されたものだった
    なぜ購読したのかは覚えていないが、たぶんコメントしたのだと思う。数年に一度通知メールが来て、そのたびに笑っていたが、数日前についに修正された

    • そのバグスレッドの購読状態が、そんな長い年月を生き延びたことに驚く
    • 私も似たようなもの。Web サイト制作を仕事にしてみようかと初めて考えていた頃、背景がデスクトップまで透明または半透明に見える Web サイトを想像して魅了された記憶がある
      html { background: transparent; } のようなものを書けば、そのまま動くべきだとずっと思っていた。ただし今回のバグ修正が実際にそれを実現するわけではない。まず、Web サイトがデフォルトで選ぶ機能ではなく、ユーザーや拡張機能が有効にできる設定だ。おそらくその方がよく、デフォルトで許可されていたらクリックジャッキングの新たな道が開けていたはずだ
    • 「Netscape Navigator 向けに登録された」というよりは、Mozilla Suite 側だ。2000年ならすでに Mozilla の時代にかなり入っていたし、Netscape のバグが Bugzilla に入っていたとも思えない
    • うわ、このバグは Firefox 自体より古いんだな
    • 次は Jira のプロジェクト間バージョンチケットが解決される番だ

  • 話題からは少し外れるが、「1か月前」のような人間に読みやすい期間表示の流行が本当に嫌いだ。普通に日付を表示してくれれば、自分で計算できる
    Outlook、少なくとも Mac 版は最悪だ。今日より前のメールは、たとえば単に「昨日」とだけ表示され、メールをクリックしないと時刻まで見えない。1日に何十通もメールを受け取るのに、50件のメッセージがずらっと「昨日」とだけ表示されても何の役にも立たない

    • 人間に読みやすい表示にマウスを乗せると正確なタイムスタンプが出る方式ならよい
    • 本気でこの流行が早く消えてほしい。メールがその日の午前6時に来たのか、夜11時に来たのかは大きな違いだ。ただ「昨日」とだけ言うのでは十分ではない
      ビールは冷たく、タイムスタンプは正確なのがよい
    • 間違ってさえいるとさらに最悪だ。Discogs は 2021年10月を「3年以上前」だと言い張る
    • 「普通に日付を表示してくれれば、自分で計算できる」というのは、私には本当に難しい。日付や時間の流れという概念そのものに、かなり大きな困難がある
    • 日付にマウスを乗せると、正確な日付と時刻が表示される

  • Firefox の Bugzilla は、間違いなく最も長く運用されているバグトラッカーの一つだ。数多くの改訂を経ているのに、元の雰囲気がかなり残っているのが印象的だ。昔はかなり荒削りで怪物のようなコードベースだった
    2000年頃、Windows 開発組織で Microsoft Access/Outlook ベースの独自バグトラッカーを置き換えるためにインスタンスを立てたことがある。複雑だったが、しばらくはほぼ最高水準のバグトラッカーだった。FogBugz もその頃に始まったばかりで、あのチームはユーザー体験を真剣に考えた初期のチームの一つだったと思う

    • 今でも Bugzilla に勝つのは簡単ではない。実際、最近の選択肢の一部は Bugzilla よりひどすぎて、どうして存在しているのか理解できないほどだ。たとえば Dwarf Fortress が使っている Mantis BT は本当にひどい
      逆に FogBugz は、機会があればいつも一度使ってみたいと思っていたツールだ

  • こういうのを見ると心が温かくなる。最近、私も24年前の Firefox バグで似たような経験をした: https://bugzilla.mozilla.org/show_bug.cgi?id=62151

    • くそ、これのせいで詰まって迷走した記憶がある

  • 長期未解決バグの中で最も気に障るのは、LibreOffice で散布図の x 軸を適切に日付形式に指定できないことだ
    https://bugs.documentfoundation.org/show_bug.cgi?id=54132
    12年前のバグだ。コメントを見ると、コードがあまりにも「ひどく複雑」なので、修正すると回帰が起きる可能性が高いとして、修正をためらう雰囲気だ

    • LibreOffice が Excel で私の好きな機能を取り入れてくれることを期待していたが、これを見ると期待が薄れる
    • スプレッドシートとグラフ作成パッケージだけが必要なら、Linux では gnumeric がよい選択肢だ
    • メンテナーが、自分たちがマージを許可したコードを怖がるようになる時って本当にいいよね

  • 次は XDG をやってほしい。これも20年待っているところ [1]
    [1] https://bugzilla.mozilla.org/show_bug.cgi?id=259356

    • XDG Base Directory が完全かつ普遍的に採用されることはないと思う。もう21年が経っている。Arch Linux がそれに従わないプログラムに対して攻撃的でなかったら、たとえばルートのユーザーディレクトリの権限をロックするようなことをしていなかったら、最近ほど広がることもなかったはず
      正直、この仕様は人々が直面している実際の問題を積極的に解決していない。採用の大半は、$HOME ディレクトリの構成が気に入らない人たちがメンテナにしつこく圧力をかけた結果で、ユーザーの99%はプログラムが XDG Base Directory に従うかどうかなど気にしていない。20年以上広く採用されてこなかった freedesktop の仕様に従って、単に「よりきれいだ」と主張できるようになる程度のもの
      個人的には、そのゆるい設定/データ/キャッシュの分離と暗黙の意図が好きではない。すべてがその分類に当てはまるわけでもないし、そうなるとシステムの挙動を予測しにくくなる。デーモンが自分のキャッシュを消すのか？ユーザーは設定フォルダをコピーして持ち歩くのか？正確には何がバックアップされるのか？仕様にはフォルダが実際にどう扱われるべきかの標準がない。意図的に曖昧なのだが、人々が仮定を置くと壊れ得る形で曖昧になっている
      ルートから /usr を分けたり、ルートから /usr/local を分けたり、/opt を置いたりするのと似ている。過ぎ去った時代の残滓が残り続けていて、さらにもう一つ作ろうとしている感じ
      うちの製品でもしぶしぶサポートしているが、その環境変数が明示的に設定されている場合に限っている。設定されていないときに全 Linux システムでデフォルトはこうあるべきだ、という XDG の挙動は100%無視している。macOS のような他の UNIX 系が期待する方式と違うからだ。Arch Linux の熱心なユーザーが毎週バグトラッカーに押し寄せて採用を求めるのを防ぐ程度には入れているが、彼らは全ユーザーの1%にも満たない。ユーザーが自分のシステム上でうちの製品のファイルをどこで見つければよいかをドキュメントで案内するだけでも十分に難しい。ユーザーが常に XDG を知っているわけでもないし、大多数にとって XDG はすでに期待される確立した慣習でもない。クリーンなユーザーディレクトリを望む人たち以外には強い価値がなく、全員をこの仕様に移すにはレガシーが多すぎる
      正直、全部考え直して、デスクトップアプリが小さな檻の外へ出られない コンテナベースの解決策 に向かうべきだ。snap アプリにかなり近い感じで。Nix から少し学べるかもしれない。世界中のすべての Linux ユーザーアプリに XDG Base Directory、さらにはユーザーディレクトリまで意識させて採用させるのは失敗だと認めるべきだ。Mac と Windows への移植をサポートするだけでも十分大変なのに、これらはこうした挙動には従わない。ユーザー権限でプログラムを実行する UNIX の権限モデルから離れて、各プログラムを独自の uid で実行すべきだ。Android はそう動いている
    • そうだね、自分もそれを待っている

  • コピーするテキストがあるのに コピーオプション がランダムに無効化されるバグを、どうか直してほしい。本当に気が狂いそう

    • 自分だけじゃないと分かってよかった
    • 25年以内に直るか見てみたい。今どきの速いWeb環境の基準では、Mozilla は時々あまりにも遅い

  • AWS は古いバグとそれに関するすべての言及を定期的に消すことで、この問題を解決している

    • バグを避ける ダチョウ戦略 だね

  • 昨年8月の関連記事:
    Happy 25th Birthday to Bugzilla
    https://news.ycombinator.com/item?id=37279543

  • すばらしい！ただし 2000-03-28 はまだ 25年前 ではない

    • 言われてみれば、かなり妙な丸め方だね
    • そうだね。正直、自分ならあと数か月待って 銀婚式の記念日 に合わせて直したと思う :P