Bug Firefox `<textarea>` yang diperbaiki setelah 25 tahun

• Bug 33654 lama di Firefox adalah masalah saat <textarea> menerapkan ROWS= dan COLS=, sehingga ruang untuk scrollbar ikut ditambahkan dan elemen tampak lebih besar dari baris/kolom yang ditentukan; kini bug ini ditutup sebagai duplikat dari Bug 1830576
• Di lingkungan dengan overlay scrollbars dinonaktifkan atau menggunakan pengaturan “always show scrollbars”, <textarea rows=N> berulang kali dihitung memiliki tinggi sekitar N+1 baris
• Diskusi awal meluas ke pewarisan font, penerapan paksa monospace, perhitungan cols berdasarkan lebar rata-rata w dan W, hingga cara reservasi ruang scrollbar, dengan testcase, patch, dan screenshot yang menumpuk dalam jangka panjang
• Dalam praktiknya, rows=1 bisa terlihat seperti 3 baris atau rows=2 tampil setinggi 3 baris, dan pada cols=80 posisi line wrap di IE dan Firefox berbeda, sehingga kontrol layout form tidak konsisten antar-browser
• Saat Bug 1830576 berstatus VERIFIED FIXED, penerapan jarak scrollbar di WebKit, Chromium, dan Firefox menjadi konsisten, dan Bug 33654 dirapikan sebagai RESOLVED DUPLICATE

---

Status dan cakupan Bug 33654

• Bug 33654 adalah cacat di mana <textarea> salah menerapkan ROWS= dan COLS=, sehingga muncul ruang tambahan untuk scrollbar horizontal dan vertikal saat overlay scrollbars dinonaktifkan
• Produk dan komponennya adalah Core :: Layout: Form Controls, yang mencakup layout dan tampilan kontrol form HTML, khususnya elemen seperti textarea
• Status saat ini adalah RESOLVED DUPLICATE of bug 1830576
  • Judul Bug 1830576 yang menjadi duplikat adalah Firefox sizes <textarea rows=N> as roughly N+1 rows tall, under an "always show scrollbars" configuration
  • Status Bug 1830576 adalah VERIFIED FIXED
• Bug ini dibuka 26 tahun lalu, dan ditutup 2 tahun lalu sebagai RESOLVED DUPLICATE
• Metadata menampilkan versi Trunk, platform x86 / All, tipe defect, prioritas P3, dan tingkat keparahan S3
• Kata kunci adalah testcase, Whiteboard adalah [html][behavior]relnote-devel, dan jumlah vote tercatat 99
• Lampiran ditampilkan sebagai 17 files, 17 obsolete files, dengan testcase, patch, dan screenshot yang terus diunggah berulang kali

Gejala yang pertama kali muncul

• Dalam laporan awal, Andrew McMillan menulis bahwa contoh TEXTAREA yang ditetapkan sebagai ROWS=5 COLS=30 tampil kira-kira seperti ROWS=7 COLS=48
• Pada komentar awal, muncul kasus INPUT TYPE=TEXT dan TEXTAREA yang tidak menggunakan font yang ditentukan dengan benar, atau area yang terlalu tinggi meski scrollbar sudah muncul
• Setelah itu diskusi mengerucut pada dugaan bahwa layout textarea menerima informasi yang salah, dengan ruang tambahan pada kolom dan satu baris ekstra pada baris
• Kemungkinan bahwa penyebabnya adalah cara mempertahankan ruang untuk scrollbar sejak awal juga dibahas lebih dini

Perhitungan font dan patch awal

• Dalam kasus di newsgroup HTML authoring, saat textarea { font-size: 8pt } dan <textarea cols="40" rows="12"> digunakan bersama, IE merender lebar dengan tepat, tetapi Mozilla tampak menghitung lebar berdasarkan font 12pt
• File uji yang menggunakan font arial berisi <textarea NAME=system_code wrap=soft rows=5 cols=30 WRAP style="font-family:arial">
• Rod menilai bahwa pada font default, perhitungan ukuran sudah benar, jadi inti masalahnya bukan sizing itu sendiri melainkan textarea yang tidak memakai font yang benar
• Kin menemukan kode yang memaksa font-family: monospace; ke area konten TextControl ketika flag PlainText editor diaktifkan
  • Jika kode ini dihapus, font yang benar akan digunakan
  • Namun dalam mode NavQuirks, string 30 karakter di dalam textarea 30 kolom masih hanya mengisi sekitar 2/3 lebar
  • Penyebab yang ditunjuk adalah cara nsFormControlHelper mengambil lebar rata-rata w dan W dari font, mengalikannya dengan jumlah kolom, lalu menambahkan lebar scrollbar untuk menghitung lebar textarea
• Patch to use the correct font. menambahkan eEditorEnableWrapHackMask ke flag inisialisasi editor plain text dan membatasi penerapan font-family: monospace; secara kondisional
• Patch ini sempat ditandai RESOLVED FIXED, tetapi dibuka kembali setelah pelapor awal memberi tahu bahwa meski COLS=... sudah benar, ROWS=... masih tetap salah

Reproduksi berulang dan bug duplikat

• Daftar bug duplikat memuat banyak kasus di mana <textarea> tampak satu baris lebih tinggi dari yang ditentukan, atau rows=1 tampak seperti 3 baris
  • 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 adalah dokumen HTML 4.01 Strict yang memungkinkan nilai rows dan cols diubah dengan tombol, dan tidak menggunakan font tag maupun variable-width font
  • Hasil perilakunya adalah selalu ada 3 kolom tambahan dari nilai yang ditentukan, dan biasanya 1 baris tambahan
  • Jika meminta rows=1, yang ditampilkan adalah 3 baris
• Pada trunk build Linux dan Win2000 tahun 2002, ada laporan bahwa <textarea cols=40 rows=2></textarea> ditampilkan sebagai 3 baris, dan jika rows=N maka yang tampil tepat N+1 baris
• Uji W3C HTML 4.01 juga digunakan sebagai referensi, dan ada komentar bahwa masalahnya terlihat jelas pada pengujian terkait ROWS
• Pada Windows 2000 dan Mozilla 0.9.3, juga diunggah contoh di mana textarea rows=1 jelas tidak tampak sebagai 1 baris

Diskusi perhitungan ruang scrollbar

• Comment 86 menjelaskan bahwa ukuran textarea dihitung sebagai nilai cols/rows yang ditentukan ditambah ruang scrollbar
• Berbeda dari IE, Mozilla hanya menampilkan scrollbar saat diperlukan, sehingga pengguna menganggap perilaku ini sebagai sesuatu yang rusak
• Tiga opsi yang mungkin pun diajukan
  • Tidak menambahkan ukuran scrollbar saat menghitung ukuran textarea
  • Selalu menampilkan scrollbar seperti IE
  • Hanya menyertakan scrollbar yang akan ditampilkan
• Opsi ketiga dikritik karena ukurannya menjadi bergantung pada apakah scrollbar ditampilkan, sementara penampilan scrollbar sendiri kembali bergantung pada ukurannya, sehingga bersifat sirkular
• Comment 87 mengusulkan opsi keempat: ROWS dan COLS hanya mengontrol ukuran konten textarea, dan jika scrollbar muncul maka textarea ikut membesar
• Setelah itu arah implementasi yang dibahas adalah melakukan reflow dengan width/height tanpa scrollbar untuk menentukan apakah scrollbar diperlukan, lalu jika perlu melakukan reflow ulang dengan width/height yang baru

Dampak yang terlihat bagi pengguna

• Ketika rows="2" ditentukan tetapi textarea yang muncul setinggi 3 baris, niat untuk memberi panduan visual tentang jumlah input menjadi kabur
  • Sebuah aplikasi web meminta teks ringkasan singkat dan menggunakan rows="2" untuk memberi isyarat input yang “lebih dari satu baris, tetapi bukan esai”
  • Karena perbedaan perilaku Firefox, IE6, dan Opera 8, nilai rows yang sama memberi panduan visual berbeda di tiap user agent
• Bahkan saat isi textarea tidak perlu discroll, komentar tetap menyebut perilaku Firefox salah
  • Untuk textarea seperti input alamat yang biasanya tidak melebihi tiga baris, penetapan rows="3" di Firefox tetap selalu menampilkan satu baris ekstra
  • Hal ini membuat halaman jadi tidak perlu lebih besar, dan pengguna bisa mengira mereka belum mengisi informasi secukupnya karena kotaknya tampak lebih besar dari perkiraan
• Pada perbandingan cols=80, ada penjelasan screenshot bahwa IE membungkus baris setelah 80 angka 1 memenuhi area hingga tepi scrollbar, sedangkan Firefox masih menyisakan ruang untuk 2 karakter lagi setelah 80 angka 1, lalu sesudah itu scrollbar horizontal muncul
• Bahkan pada 2019 masih ada komentar bahwa masalah ini tetap ada, dan kartu Trello Discord Chat bar is a line taller than usual on Firefox diberikan sebagai contoh dampaknya

Upaya patch yang berlangsung lama

• Hideo Saito beberapa kali melampirkan patch dan testcase
  • patch for rows and cols
  • testcase patch wrap="off"
  • base patch
  • additional patch for another bug
  • patch which does not remove space
• Salah satu pendekatan adalah menjalankan nsTextControlFrame::Reflow dengan intrinsic size tanpa scrollbar, lalu jika scrollbar ada, menambahkan ukuran scrollbar ke intrinsic size dan melakukan reflow ulang
• Pendekatan untuk memodifikasi GetScrollbarStyles agar text control frame bisa mengatur apakah scrollbar akan auto, hidden, atau scroll juga dibahas
• roc lebih memilih penanganan dilakukan di nsTextControlFrame daripada memasukkan terlalu banyak perubahan ke nsGfxScrollFrame
• Patch-patch berikutnya terus bolak-balik direview dan dikerjakan ulang dengan mekanisme seperti SetScrollbarStyles, GetScrollbarStyles, SetScrollbarSpace, GetScrollbarOverflowState, FrameNeedsReflow, dan post-reflow callback
• Beberapa patch mendapat review- atau ditandai obsolete, dan reviewer menunjukkan perlunya pembaruan agar sesuai dengan trunk

Solusi sementara dan keterbatasannya

• Ada usulan bahwa masalah ini bisa diatasi dengan menambahkan CSS textarea{ overflow-x: hidden }
• Namun metode ini hanya berlaku jika scrollbar horizontal memang tidak dibutuhkan
• Komentar lain membantah bahwa bug ini tidak bisa diperbaiki hanya dengan CSS overflow, dan Firefox adalah satu-satunya browser yang merender textarea dengan satu baris tambahan
• Emilio Cobos Álvarez mengatakan penyebabnya tampak berasal dari ukuran scrollbar, dan bahwa menerapkan scrollbar-width: none pada <textarea> tampaknya bisa menyelesaikannya
• Komentar yang sama juga menambahkan bahwa bug itu sendiri tetap harus diperbaiki

Ringkasan akhir

• Tiga tahun lalu BugBot meminta peninjauan kenaikan severity dengan alasan meski severity bug ini relatif rendah yaitu S3, ada 27 bug duplikat, 103 vote, dan 91 CC
• Ringkasan bug berubah dari TEXTAREA incorrectly applying ROWS= and COLS= menjadi TEXTAREA incorrectly applying ROWS= and COLS= (horizontal / vertical scrollbar extra space, with overlay scrollbars disabled)
• Daniel Holbert menambahkan Bug 1830576 Firefox sizes <textarea rows=N> as roughly N+1 rows tall, under an "always show scrollbars" configuration sebagai dependency
• Luke Warlow bertanya apakah bug ini bisa ditutup karena Bug 1830576 sudah diperbaiki, sehingga penerapan jarak scrollbar di WebKit, Chromium, dan Firefox kini konsisten
• Emilio Cobos Álvarez setuju, dan Bug 33654 diubah dari NEW menjadi RESOLVED lalu ditutup sebagai DUPLICATE
• Bug duplikat yang dituju ditetapkan sebagai Bug 1830576, dan bug tersebut berstatus VERIFIED FIXED

[GN⁺]

Opini Hacker News

• Ha! Saya berlangganan bug ini selama sebagian besar dari 25 tahun itu. Saat itu Firefox belum ada, dan ini terdaftar sebagai bug di pihak Mozilla sekitar masa itu, bukan Netscape Navigator
  Saya tidak ingat kenapa berlangganan, tapi mungkin karena pernah berkomentar. Setiap beberapa tahun sekali ada email notifikasi yang masuk dan selalu membuat saya tertawa, lalu beberapa hari lalu akhirnya diperbaiki

  • Menakjubkan bahwa langganan thread bug itu tetap bertahan selama waktu sepanjang itu
  • Saya juga mirip. Saya ingat saat pertama kali mempertimbangkan apakah akan mencoba membuat situs web sebagai pekerjaan, saya terpesona membayangkan situs web yang latar belakangnya terlihat transparan atau semitransparan sampai ke desktop
    Saya selalu berpikir kalau menulis sesuatu seperti html { background: transparent; } seharusnya langsung bekerja. Namun perbaikan bug ini sebenarnya bukan melakukan itu. Pertama-tama, ini bukan fitur yang dipilih situs web secara default, melainkan pengaturan yang bisa diaktifkan pengguna atau ekstensi. Mungkin itu lebih baik, karena jika diizinkan secara default, akan terbuka jalur baru untuk clickjacking
  • Daripada “terdaftar untuk Netscape Navigator”, lebih tepatnya ini di pihak Mozilla Suite. Tahun 2000 sudah cukup jauh masuk ke era Mozilla, dan sepertinya bug Netscape juga tidak akan masuk ke Bugzilla
  • Wah, bug ini lebih tua daripada Firefox sendiri
  • Berikutnya giliran tiket versi lintas proyek di Jira yang diselesaikan

• Sedikit melenceng dari topik, tapi saya benar-benar tidak suka tren penanda durasi yang mudah dibaca manusia seperti “sebulan lalu”. Tampilkan saja tanggalnya, nanti saya bisa menghitung sendiri
  Outlook, setidaknya versi Mac, adalah yang terburuk. Email sebelum hari ini, misalnya, hanya ditampilkan sebagai “kemarin”, dan waktu baru terlihat kalau emailnya diklik. Saya menerima puluhan email per hari, jadi kalau 50 pesan berderet semuanya hanya bertuliskan “kemarin”, itu sama sekali tidak berguna

  • Akan bagus kalau saat kursor diarahkan ke tampilan yang mudah dibaca manusia itu, muncul timestamp yang tepat
  • Saya sungguh berharap tren ini cepat hilang. Apakah email datang pukul 6 pagi hari itu atau pukul 11 malam adalah perbedaan besar. Hanya mengatakan “kemarin” saja tidak cukup
    Bir harus dingin, timestamp harus tepat
  • Kalau sampai salah, lebih parah lagi. Discogs bersikeras menyebut Oktober 2021 sebagai “lebih dari 3 tahun lalu”
  • “Tampilkan saja tanggalnya, nanti saya bisa menghitung sendiri” itu benar-benar sulit bagi saya. Saya punya cukup banyak kesulitan dengan konsep tanggal atau berlalunya waktu itu sendiri
  • Kalau kursor diarahkan ke tanggal, tanggal dan waktu yang tepat akan terlihat

• Bugzilla milik Firefox jelas merupakan salah satu pelacak bug yang paling lama berjalan. Walau sudah melalui banyak revisi, mengesankan bahwa nuansa aslinya masih cukup terasa. Dulu codebase-nya cukup kasar dan seperti monster
  Sekitar tahun 2000, di sebuah organisasi pengembangan Windows, kami pernah memasang instance untuk menggantikan pelacak bug buatan sendiri berbasis Microsoft Access/Outlook. Rumit, tetapi untuk beberapa waktu hampir termasuk pelacak bug terbaik. FogBugz juga baru mulai sekitar masa itu, dan menurut saya tim itu termasuk salah satu tim awal yang serius mempertimbangkan pengalaman pengguna

  • Bahkan sekarang pun tidak mudah mengalahkan Bugzilla. Malah beberapa pilihan zaman sekarang begitu jauh lebih buruk daripada Bugzilla sampai sulit dipahami bagaimana mereka bisa ada. Misalnya Mantis BT yang dipakai Dwarf Fortress benar-benar buruk
    Sebaliknya, FogBugz adalah alat yang selalu ingin saya coba kalau ada kesempatan

• Hal seperti ini membuat hati terasa hangat. Baru-baru ini saya juga mengalami hal serupa pada bug Firefox berumur 24 tahun: https://bugzilla.mozilla.org/show_bug.cgi?id=62151

  • Sial, saya ingat pernah tersangkut dan kebingungan gara-gara ini

• Di antara bug lama yang belum terselesaikan, yang paling mengganggu adalah di LibreOffice, sumbu x pada scatter plot tidak bisa ditetapkan dengan benar sebagai format tanggal
  https://bugs.documentfoundation.org/show_bug.cgi?id=54132
  Ini bug berumur 12 tahun. Kalau melihat komentarnya, ada suasana enggan memperbaikinya karena kodenya terlalu “sangat rumit” dan besar kemungkinan memicu regresi jika diperbaiki

  • Saya berharap LibreOffice mengambil fitur-fitur Excel yang saya sukai, tapi melihat ini ekspektasi saya jadi berkurang
  • Jika yang dibutuhkan hanya spreadsheet dan paket pembuatan grafik, di Linux gnumeric adalah pilihan yang bagus
  • Memang menyenangkan saat para maintainer mulai takut pada kode yang mereka sendiri izinkan untuk digabungkan

• Berikutnya, saya berharap mereka menangani XDG. Yang ini juga sudah ditunggu selama 20 tahun [1]
  [1] https://bugzilla.mozilla.org/show_bug.cgi?id=259356

  • Sepertinya Direktori Dasar XDG tidak akan pernah diadopsi secara lengkap dan universal. Sudah 21 tahun berlalu. Kalau Arch Linux tidak bersikap agresif terhadap program yang tidak mengikutinya, misalnya dengan mengunci izin direktori pengguna root, adopsinya mungkin tidak akan sebesar belakangan ini
    Sejujurnya, spesifikasi ini tidak secara aktif menyelesaikan masalah nyata yang dialami orang. Sebagian besar adopsinya adalah hasil dari orang-orang yang terganggu oleh susunan direktori $HOME lalu mendesak para maintainer tanpa henti, sementara 99% pengguna tidak peduli apakah sebuah program mengikuti Direktori Dasar XDG atau tidak. Ini hanya membuat orang bisa berkata bahwa sistemnya “lebih rapi” karena mengikuti spesifikasi freedesktop yang selama lebih dari 20 tahun belum diadopsi luas
    Secara pribadi, saya tidak menyukai pemisahan konfigurasi/data/cache yang longgar itu maupun niat implisit di baliknya. Tidak semuanya cocok masuk ke kategori tersebut, dan itu membuat perilaku sistem sulit diprediksi. Apakah daemon akan menghapus cache saya? Apakah pengguna akan menyalin folder konfigurasi ke mana-mana? Apa persisnya yang akan dicadangkan? Spesifikasinya tidak punya standar tentang bagaimana folder-folder itu sebenarnya harus diperlakukan. Memang sengaja dibuat samar, tetapi samarnya dengan cara yang bisa rusak ketika orang membuat asumsi
    Ini mirip dengan memisahkan /usr dari root, memisahkan /usr/local dari root, atau menyediakan /opt. Rasanya seperti sisa-sisa era lampau yang terus bertahan, dan kini ingin membuat satu lagi
    Di produk kami pun kami mendukungnya dengan setengah hati, tetapi hanya jika variabel lingkungan terkait disetel secara eksplisit. Perilaku XDG yang mengatakan bahwa nilai default di semua sistem Linux harus seperti ini ketika tidak disetel kami abaikan 100%. Karena itu berbeda dari cara yang diharapkan UNIX lain seperti MacOS. Kami hanya memasukkan dukungan secukupnya untuk mencegah para penggemar berat Arch Linux membanjiri bug tracker setiap minggu dan menuntut adopsi, padahal mereka bahkan tidak sampai 1% dari total pengguna. Mendokumentasikan di mana pengguna bisa menemukan file produk kami di sistem mereka saja sudah cukup sulit. Pengguna juga tidak selalu tahu XDG, dan bagi kebanyakan orang XDG bukanlah konvensi mapan yang sudah mereka harapkan. Tidak ada nilai kuat selain bagi orang-orang yang menginginkan direktori pengguna yang bersih, sementara warisannya terlalu banyak untuk memindahkan semua orang ke spesifikasi ini
    Sejujurnya, semuanya perlu dipikirkan ulang dan beralih ke solusi berbasis container yang membuat aplikasi desktop tidak bisa keluar dari kurungan kecilnya. Kurang lebih seperti aplikasi snap. Mungkin juga bisa belajar sedikit dari Nix. Kita harus mengakui bahwa membuat semua aplikasi pengguna Linux di seluruh dunia peduli dan mengadopsi Direktori Dasar XDG, bahkan direktori pengguna, adalah kegagalan. Mendukung port Mac dan Windows saja sudah cukup sulit, dan keduanya tidak mengikuti perilaku seperti ini. Kita harus keluar dari model izin UNIX yang menjalankan program dengan hak pengguna, dan menjalankan tiap program dengan uid-nya sendiri. Android bekerja seperti itu
  • Benar, saya juga menantikan itu

• Semoga bug yang membuat opsi salin dinonaktifkan secara acak padahal ada teks yang bisa disalin akhirnya diperbaiki. Benar-benar bikin frustrasi

  • Syukurlah ternyata bukan cuma saya yang mengalaminya
  • Kita lihat saja apakah diperbaiki dalam 25 tahun. Untuk ukuran web yang bergerak cepat seperti sekarang, Mozilla kadang terlalu lambat

• AWS menyelesaikan masalah ini dengan secara berkala menghapus bug lama beserta semua penyebutan tentangnya

  • Itu strategi burung unta untuk menghindari bug

• Tulisan terkait Agustus lalu:
  Happy 25th Birthday to Bugzilla
  https://news.ycombinator.com/item?id=37279543

• Keren! Hanya saja 2000-03-28 belum 25 tahun lalu

  • Kalau dipikir-pikir, itu cara pembulatan yang cukup aneh
  • Benar. Sejujurnya kalau saya, saya mungkin akan menunggu beberapa bulan lagi dan memperbaikinya bertepatan dengan hari jadi perak :P