25 yıl sonra düzeltilen Firefox `<textarea>` hatası

• Firefox’un eski Bug 33654 kaydı, <textarea> öğesinde ROWS= ve COLS= uygulanırken kaydırma çubuğu alanının da eklenmesi nedeniyle öğenin belirtilen satır ve sütundan daha büyük görünmesi sorunuydu; şimdi Bug 1830576’nın yineleneni olarak kapatıldı
• Overlay scrollbars kapalıyken veya “always show scrollbars” ayarı kullanılan ortamlarda <textarea rows=N> yüksekliğinin yaklaşık N+1 satır olarak hesaplanması tekrarlanıyordu
• İlk tartışmalar; yazı tipi kalıtımı, zorunlu monospace uygulaması, w ve W ortalama genişliğine dayalı cols hesabı ve kaydırma çubuğu alanı ayırma yöntemine kadar genişledi; test case’ler, yamalar ve ekran görüntüleri uzun süre boyunca birikti
• Pratikte rows=1 3 satırmış gibi görünebiliyor ya da rows=2 3 satır yüksekliğinde görünüyordu; cols=80 durumunda ise IE ve Firefox’ta satır kırılma konumu farklılaşıyordu; yani form düzeni kontrolü tarayıcıya göre kayıyordu
• Bug 1830576 VERIFIED FIXED durumuna gelince WebKit, Chromium ve Firefox’un kaydırma çubuğu aralığı uygulaması tutarlı hale geldi ve Bug 33654 RESOLVED DUPLICATE olarak sonuçlandırıldı

---

Bug 33654’ün durumu ve kapsamı

• Bug 33654, <textarea> öğesinin ROWS= ve COLS= değerlerini hatalı uygulayıp overlay scrollbars devre dışıyken yatay ve dikey kaydırma çubuğu için ek alan bırakmasına yol açan bir hataydı
• Ürün ve bileşen Core :: Layout: Form Controls; yani HTML form denetimlerinin yerleşimi ve görünümü, özellikle de textarea gibi öğeler kapsama giriyor
• Güncel durum RESOLVED DUPLICATE of bug 1830576
  • Yinelenen hata olan Bug 1830576’nın başlığı: Firefox sizes <textarea rows=N> as roughly N+1 rows tall, under an "always show scrollbars" configuration
  • Bug 1830576’nın durumu VERIFIED FIXED
• Hata 26 yıl önce açıldı ve 2 yıl önce RESOLVED DUPLICATE olarak kapatıldı
• Meta veride sürüm Trunk, platform x86 / All, tür defect, öncelik P3, önem derecesi S3 görünüyor
• Anahtar kelime testcase, Whiteboard ise [html][behavior]relnote-devel; oy sayısı da 99 olarak listeleniyor
• Ekler kısmında 17 files, 17 obsolete files görünüyor; test case’ler, yamalar ve ekran görüntüleri tekrar tekrar yüklenmiş

İlk ortaya çıkan belirtiler

• İlk raporda Andrew McMillan, ROWS=5 COLS=30 olarak ayarlanmış bir TEXTAREA örneğinin yaklaşık ROWS=7 COLS=48 gibi göründüğünü yazdı
• İlk yorumlarda INPUT TYPE=TEXT ve TEXTAREA öğelerinin belirtilen yazı tipini doğru kullanmadığı ya da kaydırma çubuğu görünse bile alanın fazla yüksek olduğu örnekler paylaşıldı
• Sonraki tartışmalarda textarea yerleşiminin yanlış bilgi aldığı; sütunlarda ek alan olduğu ve satır sayısının da bir fazla olduğu yönünde görüş birliği oluştu
• Kaydırma çubuğu için alanın önceden korunması yöntemi de erken dönemde olası nedenlerden biri olarak ele alındı

Yazı tipi hesabı ve ilk yamalar

• HTML authoring newsgroup örneğinde textarea { font-size: 8pt } ile <textarea cols="40" rows="12"> birlikte kullanıldığında IE genişliği doğru render ederken Mozilla, genişliği sanki 12pt yazı tipine göre hesaplıyormuş gibi görünüyordu
• arial yazı tipini kullanan test dosyasında <textarea NAME=system_code wrap=soft rows=5 cols=30 WRAP style="font-family:arial"> yer alıyordu
• Rod, varsayılan yazı tipinde boyut hesabı doğru olduğu için asıl sorunun sizing’den çok textarea’nın doğru yazı tipini kullanmaması olduğunu düşündü
• Kin, editor’ün PlainText bayrağı ayarlıysa TextControl içerik alanına zorla font-family: monospace; uygulayan kodu buldu
  • Bu kod kaldırılınca doğru yazı tipi kullanılıyordu
  • Ancak NavQuirks modunda 30 sütunluk textarea içindeki 30 karakterlik dizenin genişliğin yalnızca yaklaşık 2/3’ünü kaplaması sorunu sürüyordu
  • Olası neden olarak nsFormControlHelper içinde yazı tipinden w ve W karakterlerinin ortalama genişliğinin alınıp sütun sayısıyla çarpılması ve üstüne kaydırma çubuğu genişliğinin eklenmesiyle textarea genişliğinin hesaplanması gösterildi
• Patch to use the correct font. adlı yama, plain text editor başlatma bayrağına eEditorEnableWrapHackMask ekliyor ve font-family: monospace; uygulamasını koşullu hale getiriyordu
• Bu yama bir ara RESOLVED FIXED olarak işaretlendi, ancak asıl rapor sahibi COLS=... düzelmiş olsa da ROWS=... hâlâ yanlış çalışıyor diyerek hatanın yeniden açılmasını sağladı

Tekrarlanan yeniden üretim ve yinelenen hatalar

• Yinelenen hata listesinde <textarea> öğesinin belirtilenden bir satır daha büyük görünmesi ya da rows=1 değerinin 3 satırmış gibi görünmesiyle ilgili çok sayıda kayıt bulunuyor
  • 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 ve cols değerlerinin düğmelerle değiştirilebildiği bir HTML 4.01 Strict belgesiydi ve font tag ya da variable-width font kullanmıyordu
  • Sonuçta her zaman belirtilenden 3 columns fazla, satır sayısında ise genelde 1 satır fazla görünüyordu
  • rows=1 istendiğinde 3 rows gösteriliyordu
• 2002 tarihli Linux ve Win2000 trunk build’lerinde <textarea cols=40 rows=2></textarea> öğesinin 3 rows olarak göründüğü, genel olarak da rows=N için tam N+1 rows gösterildiği raporlandı
• W3C HTML 4.01 testleri de referans olarak kullanıldı ve ROWS ile ilgili testte sorunun çok net görüldüğü yorumlandı
• Windows 2000 ve Mozilla 0.9.3 üzerinde de rows=1 textarea’nın açıkça 1 row gibi görünmediğini gösteren örnekler paylaşıldı

Kaydırma çubuğu alanı hesabı tartışması

• Comment 86, textarea boyutunun belirtilen cols/rows değerlerine scrollbar alanı eklenerek hesaplandığını açıklıyordu
• IE’den farklı olarak Mozilla kaydırma çubuklarını yalnızca gerektiğinde gösterdiği için kullanıcıların bunu bozuk davranış olarak algıladığı yorumu yapıldı
• Olası üç seçenek önerildi
  • textarea boyutu hesaplanırken kaydırma çubuğu boyutunu eklememek
  • IE gibi kaydırma çubuklarını her zaman göstermek
  • Yalnızca gösterilecek kaydırma çubuğunu dahil etmek
• Üçüncü seçenekte boyutun kaydırma çubuğunun görünüp görünmemesine bağlı olması ve bunun da tekrar boyuta bağlı olması nedeniyle döngüsel bir sorun doğduğu belirtildi
• Comment 87, ROWS ve COLS değerlerinin yalnızca textarea içerik boyutunu kontrol etmesini; kaydırma çubuğu görünürse textarea’nın büyümesini dördüncü seçenek olarak önerdi
• Sonraki uygulama yönü, önce kaydırma çubuğu olmayan width/height ile reflow yapıp kaydırma çubuğuna ihtiyaç olup olmadığını belirlemek, sonra gerekirse yeni width/height ile yeniden reflow yapmak şeklinde tartışıldı

Kullanıcıya görünen etkiler

• rows="2" verilmesine rağmen 3 satır yüksekliğinde bir textarea görünmesi, kullanıcıya beklenen giriş miktarını görsel olarak anlatma amacını zayıflatıyordu
  • Bir web uygulaması kısa özet metni istiyor ve rows="2" kullanarak “tek satırdan fazla ama deneme yazısı değil” düzeyinde giriş beklendiğini anlatıyordu
  • Firefox, IE6 ve Opera 8 arasındaki davranış farkı yüzünden aynı rows değeri farklı kullanıcı aracıları için farklı görsel ipuçları üretiyordu
• textarea içeriği kaydırılmıyor olsa bile Firefox davranışının yine de hatalı olduğu yönünde yorumlar sürdü
  • Adres girişi gibi çoğunlukla üç satırı aşmayacak alanlarda rows="3" verilse bile Firefox her zaman fazladan bir satır gösteriyordu
  • Bu da sayfanın gereksiz yere büyümesine yol açıyor ve kullanıcıların kutu beklenenden büyük olduğu için yeterli bilgi girmediklerini düşünmesine neden olabiliyordu
• cols=80 karşılaştırmasında IE, 80 adet 1 karakterini kaydırma çubuğu kenarına kadar doldurup sonra satır kırarken Firefox’ta 80 adet 1 sonrasında 2 karakter daha sığacak boşluk kalıyor ve ardından yatay kaydırma çubuğu çıkıyordu; ekran görüntüsü bunu gösteriyordu
• 2019’da bile sorunun sürdüğünü söyleyen yorumlar vardı; Discord’un Chat bar is a line taller than usual on Firefox Trello kartı da etki örneği olarak verildi

Uzun yıllara yayılan yama girişimleri

• Hideo Saito birden çok kez yama ve test case ekledi
  • patch for rows and cols
  • wrap="off" yaması için test case
  • base patch
  • additional patch for another bug
  • patch which does not remove space
• Yaklaşımlardan biri, nsTextControlFrame::Reflow işlemini kaydırma çubukları hariç intrinsic size ile yürütmek; ardından kaydırma çubuğu varsa intrinsic size’a bu boyutu ekleyip yeniden reflow yapmaktı
• GetScrollbarStyles üzerinde değişiklik yaparak text control frame’in kaydırma çubuklarını auto, hidden, scroll arasında nasıl yöneteceğini belirleme yaklaşımı da ele alındı
• roc, çok sayıda değişikliği nsGfxScrollFrame içine koymak yerine bunun nsTextControlFrame içinde ele alınmasını tercih etti
• Sonraki yamalarda SetScrollbarStyles, GetScrollbarStyles, SetScrollbarSpace, GetScrollbarOverflowState, FrameNeedsReflow ve post-reflow callback gibi mekanizmalar etrafında inceleme ve yeniden çalışma tekrarlandı
• Bazı yamalar review- aldı ya da obsolete oldu; yorumcular trunk ile uyumlu güncellemeler gerektiğini belirtti

Geçici kaçınma yolları ve sınırlar

• CSS textarea{ overflow-x: hidden } eklenirse sorunun çözülebileceği önerildi
• Ancak bunun yalnızca yatay kaydırma çubuğunun gerekmeyeceği durumlarda geçerli olduğu da belirtildi
• Başka yorumlarda ise bu hatanın yalnızca CSS overflow ile düzeltilemeyeceği; textarea’ya fazladan bir satır ekleyerek render eden tek tarayıcının Firefox olduğu savunuldu
• Emilio Cobos Álvarez, sebebin kaydırma çubuğu boyutu gibi göründüğünü ve <textarea> öğesine scrollbar-width: none uygulanınca sorunun çözülmüş göründüğünü söyledi
• Aynı yorumda buna rağmen hatanın kendisinin yine de düzeltilmesi gerektiği de eklendi

Son durum

• 3 yıl önce BugBot, bu hatanın önem derecesi görece düşük S3 olsa da 27 yinelenen kayıt, 103 oy ve 91 CC bulunduğunu belirterek severity artışı değerlendirmesi istedi
• Hata özeti TEXTAREA incorrectly applying ROWS= and COLS= iken daha sonra TEXTAREA incorrectly applying ROWS= and COLS= (horizontal / vertical scrollbar extra space, with overlay scrollbars disabled) olarak değiştirildi
• Daniel Holbert, Bug 1830576 Firefox sizes <textarea rows=N> as roughly N+1 rows tall, under an "always show scrollbars" configuration kaydını bağımlılık olarak ekledi
• Luke Warlow, Bug 1830576 düzeltildiğine göre WebKit, Chromium ve Firefox’un kaydırma çubuğu aralığı uygulamasının artık tutarlı hale geldiğini, dolayısıyla bu hatanın kapatılıp kapatılamayacağını sordu
• Emilio Cobos Álvarez buna katıldı ve Bug 33654 NEW durumundan RESOLVED durumuna geçirilerek DUPLICATE olarak kapatıldı
• Yinelenen hedef olarak Bug 1830576 atandı ve bu hata VERIFIED FIXED durumunda

[GN⁺]

Hacker News yorumları

• Ha! Bu hatayı o 25 yılın büyük bölümünde takip ediyordum. O zaman Firefox yoktu; bu, Netscape Navigator’a değil, ondan önce/sonra Mozilla tarafında açılmış bir hataydı.
  Neden abone olduğumu hatırlamıyorum ama muhtemelen yorum yazmışımdır. Birkaç yılda bir bildirim e-postası gelirdi ve hep güldürürdü; birkaç gün önce nihayet düzeltildi.

  • O hata başlığına aboneliğin bunca yıl boyunca ayakta kalmış olması şaşırtıcı.
  • Ben de benzerim. Web sitesi yapmayı iş olarak denemeyi ilk düşündüğüm zamanlarda, arka planı masaüstüne kadar şeffaf ya da yarı şeffaf görünen bir web sitesi hayal edip büyülendiğimi hatırlıyorum.
    html { background: transparent; } gibi bir şey yazınca bunun doğrudan çalışması gerektiğini hep düşünürdüm. Yine de bu hata düzeltmesi aslında bunu yapmıyor. Öncelikle web sitelerinin varsayılan olarak seçtiği bir özellik değil; kullanıcının ya da bir eklentinin açabileceği bir ayar. Muhtemelen böylesi daha iyi; varsayılan olarak izin verilseydi clickjacking için yeni bir yol açılmış olurdu.
  • “Netscape Navigator için açıldı” demektense Mozilla Suite tarafı demek daha doğru. 2000 yılına gelindiğinde zaten Mozilla dönemine epey girilmişti; Netscape hatalarının Bugzilla’ya gelmiş olacağını da sanmıyorum.
  • Vay, bu hata Firefox’un kendisinden bile eskiymiş.
  • Sırada Jira’daki projeler arası sürüm biletinin çözülmesi var.

• Konudan biraz sapacak ama “bir ay önce” gibi insanın okuması kolay süre gösterimi modasından gerçekten nefret ediyorum. Sadece tarihi gösterin, hesabını ben yaparım.
  Outlook, en azından Mac sürümü, en kötüsü. Bugünden önceki e-postalar örneğin sadece “dün” diye görünüyor; saati görmek için e-postaya tıklaman gerekiyor. Günde onlarca e-posta alıyorum; 50 mesaj arka arkaya sadece “dün” diye görünüyorsa hiçbir işe yaramıyor.

  • İnsan okunur ifadenin üzerine gelince tam zaman damgasının görünmesi iyi olurdu.
  • Bu modanın gerçekten bir an önce yok olmasını istiyorum. E-postanın o gün sabah 6’da mı, gece 11’de mi geldiği arasında çok büyük fark var. Sadece “dün” demek yeterli değil.
    Bira soğuk, zaman damgaları kesin olsun.
  • Bir de yanlışsa daha da berbat. Discogs, Ekim 2021 için “3 yıldan fazla önce” diye ısrar ediyor.
  • “Sadece tarihi gösterin, hesabını ben yaparım” kısmı benim için gerçekten zor. Tarih ya da zamanın akışı kavramıyla ilgili epey büyük zorluk yaşıyorum.
  • Tarihin üzerine gelince tam tarih ve saat görünüyor.

• Firefox’un Bugzilla’sı kesinlikle en uzun süredir çalışan hata takip sistemlerinden biri. Pek çok revizyondan geçmiş olmasına rağmen özgün hissini epey koruması etkileyici. Eskiden oldukça kaba ve canavar gibi bir kod tabanıydı.
  2000 civarında bir Windows geliştirme organizasyonunda, Microsoft Access/Outlook tabanlı şirket içi hata takip sisteminin yerine bir örneğini kurmuştum. Karmaşıktı ama bir süre için neredeyse en iyi hata takip sistemlerinden biriydi. FogBugz da o sıralarda yeni başlamıştı; o ekibin kullanıcı deneyimini ciddiye alan erken ekiplerden biri olduğunu düşünüyorum.

  • Bugzilla’yı bugün bile geçmek kolay değil. Hatta günümüzdeki bazı seçenekler Bugzilla’dan o kadar kötü ki nasıl var olduklarını anlamak zor. Örneğin Dwarf Fortress’ın kullandığı Mantis BT gerçekten berbat.
    Buna karşılık FogBugz’ı fırsat bulursam hep bir kez denemek istemişimdir.

• Böyle şeyler içimi ısıtıyor. Yakın zamanda ben de 24 yıllık bir Firefox hatasında benzer bir şey yaşadım: https://bugzilla.mozilla.org/show_bug.cgi?id=62151

  • Kahretsin, bunun yüzünden takılıp debelendiğimi hatırlıyorum.

• Uzun süredir çözülmemiş hatalar içinde en sinir bozucu olanlardan biri, LibreOffice’te saçılım grafiğinin x eksenini düzgün şekilde tarih biçimi olarak ayarlayamamak.
  https://bugs.documentfoundation.org/show_bug.cgi?id=54132
  12 yıllık bir hata. Yorumlara bakınca, kodun fazla “korkunç derecede karmaşık” olduğu ve düzeltmenin regresyona yol açma ihtimalinin yüksek olduğu gerekçesiyle düzeltmeye isteksiz bir hava var.

  • LibreOffice’in Excel’de sevdiğim özellikleri getirmesini umuyordum; bunu görünce beklentim azaldı.
  • Sadece hesap tablosu ve grafik çizim paketi gerekiyorsa Linux’ta gnumeric iyi bir seçenek.
  • Bakımcıların, birleşmesine izin verdikleri koddan korkmaya başlaması gerçekten harika.

• Sırada XDG’yi halletmelerini isterim. Onu da 20 yıldır bekliyorum [1]
  [1] https://bugzilla.mozilla.org/show_bug.cgi?id=259356

  • XDG temel dizinlerinin eksiksiz ve evrensel olarak benimseneceğini sanmıyorum. Üzerinden 21 yıl geçti bile. Arch Linux, buna uymayan programlara karşı agresif davranmasaydı; örneğin kök kullanıcı dizininin izinlerini kilitlemek gibi şeyler yapmasaydı, bugün olduğu kadar büyümüş bile olmazdı
    Açıkçası bu spesifikasyon, insanların yaşadığı gerçek sorunları etkin biçimde çözmüyor. Benimsenmesinin büyük kısmı, $HOME dizininin düzeninden rahatsız olan insanların bakımcıları bıktıracak şekilde sıkıştırmasının sonucu; kullanıcıların %99’u bir programın XDG temel dizinlerine uyup uymadığını umursamıyor. 20 yılı aşkın süredir yaygın biçimde benimsenememiş bir freedesktop spesifikasyonuna uyup sadece “daha temiz” olduğunu iddia edebilmenizi sağlıyor
    Kişisel olarak o gevşek yapılandırma/veri/önbellek ayrımını ve örtük niyetleri sevmiyorum. Her şey o kategorilere sığmıyor; bu da sistem davranışını tahmin etmeyi zorlaştırıyor. Bir daemon önbelleğimi silecek mi? Kullanıcı ayarlar klasörünü kopyalayıp yanında mı taşıyacak? Tam olarak ne yedeklenecek? Spesifikasyonda klasörlerin gerçekte nasıl ele alınması gerektiğine dair bir standart yok. Bilerek muğlak, ama insanların varsayımlar yaptığında bozulabilecek şekilde muğlak
    Kökten /usr’yi ayırmaya, kökten /usr/local’ı ayırmaya ya da /opt bulundurmaya benziyor. Geçmiş bir dönemin kalıntıları varlığını sürdürüyor ve sanki bir tane daha yaratmaya çalışıyoruz
    Biz de ürünümüzde gönülsüzce destekliyoruz, ama yalnızca ilgili ortam değişkeni açıkça ayarlanmışsa. Ayarlanmadığında tüm Linux sistemlerinde varsayılanın böyle olması gerektiğini söyleyen XDG davranışını %100 yok sayıyoruz. Çünkü MacOS gibi diğer UNIX türevlerinin beklediği yöntemden farklı. Arch Linux fanatiklerinin her hafta hata takipçisine doluşup benimsememizi talep etmesini engelleyecek kadarını ekledik; onlar da toplam kullanıcıların %1’i bile değil. Kullanıcılara kendi sistemlerinde ürün dosyalarımızı nerede bulacaklarını belgelerle anlatmak bile yeterince zor. Kullanıcılar her zaman XDG’yi bilmiyor; çoğu için XDG zaten bekledikleri yerleşik bir teamül değil. Temiz bir kullanıcı dizini isteyenler dışında güçlü bir değeri yok, ama herkesi bu spesifikasyona taşımak için çok fazla miras yükü var
    Açıkçası her şeyi baştan düşünmeli ve masaüstü uygulamalarının küçük hapishanelerinden çıkamadığı konteyner tabanlı bir çözüme gitmeliyiz. Neredeyse snap uygulamaları gibi. Nix’ten de biraz ders alınabilir. Dünyadaki tüm Linux kullanıcı uygulamalarının XDG temel dizinlerini, hatta kullanıcı dizinini bile önemseyip benimsemesini sağlamanın başarısızlık olduğunu kabul etmeliyiz. Mac ve Windows portlarını desteklemek bile yeterince zorken, onlar bu davranışı izlemiyor. Programları kullanıcı yetkileriyle çalıştıran UNIX izin modelinden çıkıp her programı kendi uid’siyle çalıştırmalıyız. Android böyle çalışıyor
  • Evet, ben de onu bekliyorum

• Kopyalanacak metin olmasına rağmen kopyala seçeneğinin rastgele devre dışı kalması hatası lütfen düzeltilsin. Gerçekten insanı çıldırtıyor

  • Bunu yaşayan tek kişinin ben olmamama sevindim
  • 25 yıl içinde düzeltiliyor mu göreceğiz. Mozilla, günümüzün hızlı web ortamı ölçütlerine göre bazen fazla yavaş kalıyor

• AWS, eski hataları ve onlara yapılan tüm atıfları düzenli olarak silerek bu sorunu çözüyor

  • Bu, hatadan kaçınmanın devekuşu stratejisi

• Geçen ağustostan ilgili yazı:
  Bugzilla’nın 25. doğum günü kutlu olsun
  https://news.ycombinator.com/item?id=37279543

• Harika! Ama 2000-03-28 henüz 25 yıl önce değil

  • Düşününce epey tuhaf bir yuvarlama yöntemi
  • Evet. Açıkçası ben olsam birkaç ay daha bekleyip gümüş yıl dönümüne denk getirerek düzeltirdim :P