22 yıl sonra düzeltilen Firefox tooltip hatası

 (bugzilla.mozilla.org)
1 puan yazan GN⁺ 2023-10-11 | 1 yorum | WhatsApp'ta paylaş
  • Firefox arka planda olsa bile tooltip’in önde kalmasına neden olan tooltip-ghost hatası, Bugzilla’da uzun süre takip edildi ve Firefox 119 dalında VERIFIED FIXED durumuna getirildi
  • İlk yeniden üretim, araç çubuğundaki bağlantı veya simgenin üzerine fareyi getirip tooltip’i gösterdikten sonra Command-Tab veya Alt-Tab ile başka bir uygulamaya geçildiğinde tooltip’in kaybolmaması şeklindeydi
  • Benzer vakalar Mac OS X, Windows, Linux’un yanı sıra Thunderbird, Sunbird ve Lightning’de de görüldü; Firefox 5.0.1’de ise fare yalnızca arka plandaki pencerenin üzerinden geçtiğinde bile tooltip ve mouse-over durumu oluşuyordu
  • Son yama, only show tooltip when document has focus şeklindeydi; yani tooltip artık yalnızca belge odaktayken gösteriliyor ve değişiklik mozilla-centrala 8ae372dc88d1 revizyonuyla işlendi
  • QA ekibi, Firefox 106.0.1 ve Ubuntu 22.04’te sorunu orijinal adımlarla yeniden üretip Nightly 120.0a1 yapısında devam etmediğini doğruladı; ardından bazı ilgili regresyon hataları ayrıca bağlandı

Arka plandaki Firefox üzerinde kalan tooltip

  • Bug 148624, Firefox arka plandayken bile tooltip’in önde kalması sorununu ele alıyor
  • Orijinal başlığı Tooltips persist in foreground when Firefox is in background, takma adı ise tooltip-ghost
  • Durum VERIFIED FIXED, hedef kilometre taşı ise 119 Branch
  • Sınıflandırması Core :: XUL, tipi defect, önem derecesi S3

İlk yeniden üretim adımları ve beklenen davranış

  • İlk raporlanan ortam Mozilla/5.0 ... Mac OS X ... Gecko/20020602 BuildID: 2002060203 idi
  • Yeniden üretim adımları basitti
    • Araç çubuğu simgesi veya bağlantısının üzerine fareyi getirin
    • Tooltip görünene kadar bekleyin
    • Command-Tab ile Mozilla’yı arka plana gönderin
  • Gerçekte küçük sarı tooltip kutusu önde kalmaya devam etti
  • Beklenen davranış, Mozilla arka plana geçtiğinde tooltip’in kaybolmasıydı
  • İlk raporu yapan kişi, tooltip’in ancak Firefox yeniden öne alınıp fare araç çubuğunun dışına taşındığında kaybolduğunu belirtti

Birden çok platformda süren yeniden üretim örnekleri

  • İlk doğrulamadan sonra platform kapsamı Mac OS X’ten All olarak değiştirildi ve aynı sorun Windows XP ile Windows 98’de de yeniden üretildi
  • Linux GTK2, Firefox 0.8, Firefox 2.0.0.14, Firefox 4 nightly, Firefox 5.0.1, Firefox 36.0, Firefox 49.0.2, Firefox 106.0.1, Firefox 113.0.2, Firefox 115.0.2 ve Firefox 117.0 gibi sürümlerde de örnekler gelmeye devam etti
  • Thunderbird, Sunbird ve Lightning ortamlarında da benzer davranışlar görüldü
    • Thunderbird 2.0.0.17 ve Lightning 0.9’da görev penceresi tooltip’inin bildirim penceresinin üzerinde kalmasına dair örnek eklendi
    • Thunderbird 102.4.1 ile Firefox 106.0.1 kombinasyonunda da GNU/Linux üzerinde yeniden üretildi
    • Firefox 117.0 ve Thunderbird 115.2.0 ile xfce ve xfwm ortamlarında da yeniden üretim adımları paylaşıldı
  • Bir kullanıcı, sorunun Firefox 115.0.2 ve GNOME 44’te sürdüğünü belirterek browser.chrome.toolbar_tips ayarıyla tooltip’leri tamamen devre dışı bırakma geçici çözümünü kullandı

Kalıcı tooltip’in ötesindeki etkiler

  • Sorun yalnızca açılmış bir tooltip’in ekranda kalması değildi; Firefox arka plandayken fare Firefox penceresindeki ilgili alanın üzerinden geçtiğinde yeni tooltip’lerin görünmesi de doğrulandı
  • Firefox 5.0.1’de Transmission öndeyken ve Firefox arka plandayken, farenin Transmission Inspector penceresi üzerinde hareket ettirilmesiyle Firefox tooltip’lerinin tetiklendiği örnek eklendi
  • Adblock Plus araç çubuğu düğmesinin büyük tooltip’inin Transmission üzerinde göründüğü örnekler de vardı
  • Transmission’ın Options tooltip’i ile Firefox’un Google arama kutusu tooltip’inin aynı anda gösterilip üst üste geldiği bir örnek de kayıtlı
  • Yer imleri araç çubuğu öğelerinde yalnızca tooltip değil, mouse-over durumu da tetikleniyordu
    • Yer imi düğmesinin durumu önce değişiyor, kısa süre sonra URL tooltip’i görünüyordu
    • Open a New Tab içindeki + düğmesi de arka plan durumunda mouse-over ve tooltip oluşturan istisnalardan biri olarak kaydedildi

Düzeltme yönü ve uygulanan yama

  • 2010’ların başındaki tartışmalarda, tooltip zamanlayıcısı çalıştığında pencerenin odağı yoksa tooltip göstermeme yaklaşımı önerildi
  • Safari ve Google Chrome, Mac üzerinde öndeki uygulama değilken tooltip göstermeyen karşılaştırma örnekleri olarak kullanıldı
  • Son yama açıklaması only show tooltip when document has focus idi
  • Yama Phabricator eki olarak yüklendi, ardından autoland ve mozilla-centrala işlendi
  • Durum ASSIGNEDdan RESOLVEDe geçti ve çözüm FIXED oldu

QA doğrulaması ve sonraki regresyonlar

  • QA ekibi, Firefox 106.0.1 ve Ubuntu 22.04’te orijinal yeniden üretim adımlarıyla sorunu doğruladı
  • Aynı yapılandırmada güncel Nightly 120.0a1 sürümünde sorunun artık sürmediği görüldü ve durum VERIFIED olarak değiştirildi
  • firefox119 durumu fixedden verifiede geçirildi
  • Bir kullanıcı, sorunun yalnızca MOZ_ENV_XINPUT2=1 iken ortaya çıktığını, MOZ_ENV_XINPUT2=0 olduğunda kaybolduğunu belirtti; bu durum bug 1809029 ile ilişkilendirildi
  • Daha sonra ilgili regresyonlar olarak şu hatalar bağlandı
    • 1857513: Yer imi kenar çubuğu tooltip’i, kenar çubuğunda odak yokken hover ile görünmüyor
    • 1861427: Başka bir uygulama odaktayken hover durumunda tooltip artık görünmüyor
    • 2043757: Windows 11’de Firefox başka bir pencere tarafından kısmen örtülüyken sekme başlığı hover ile görünmüyor

İlgili okumalar

1 yorum

 
GN⁺ 2023-10-11
Hacker News yorumları

  • Firefox kod tabanında hataların nasıl bulunup düzeltildiğini merak ediyorsanız, Mike Conley birkaç yıldır Mozilla’da yaptığı geliştirme çalışmalarını her hafta canlı yayınlıyor
    Kayıtların önemli bir kısmı, backlog’dan bir hata seçip onu çok titiz biçimde izleyerek yakalama sürecinden oluşuyor
    Özellikle programlamaya yeni başladıysanız ve gerçek bir kod tabanında çalışmanın nasıl göründüğünü görmek istiyorsanız öneririm: https://youtube.com/@mikeconleytoronto

    • Üniversite yıllarımda, bu hatanın kaydedilmesinden neredeyse benzer derecede uzun zaman önce Mozilla’da epey gönüllü çalışmıştım
      Başta QA ekibinde hata triage’ı yapıyordum; Bugzilla bileşeninin doğru olup olmadığını, yeniden üretme adımlarının mantıklı olup olmadığını vb. kontrol ediyordum
      Hiç pratik deneyimi olmayan biri olarak bile, büyük ölçekli bir projenin nasıl yürütüldüğünü ve gerçek geliştiricilerin düzeltmeleri ve özellikleri nasıl ele aldığını görmek başlı başına büyük bir öğrenme fırsatıydı; diff, patch, CI/CD gibi kavramlarla da tanıştım. O dönemde nightly build olduğu için teknik olarak sürekli entegrasyon değildi ama yön doğruydu
      Sonraları uygulamayı nasıl derleyeceğimi öğrendim; özellikle Windows’ta gerçekten zordu. Firefox, Thunderbird ve o zamanlar hâlâ var olan Mozilla Suite’i derledim; tarayıcı, e-posta, HTML düzenleyici vb. entegre bir yapıdaydı
      Sonunda birkaç hata düzeltmesine de bizzat katkıda bulundum. Yazım hatası ya da hizası bozuk bir ikonu düzeltmek gibi şeylerdi ama milyonlarca kişinin gerçekten kullandığı kodun dağıtıma çıktığını hissetmek inanılmazdı
      Mezuniyetten sonraki ilk işimde bu deneyim doğrudan işime yaradı. Bir startup’ta IT destek ve QA ile başladım; derleme ve dağıtım otomasyonu hiç yoktu. Biri SVN’e push yapsa bile build’in bozulup bozulmadığı günlerce fark edilmeyebiliyordu
      Mozilla’da öğrendiklerime dayanarak Buildbot, CruiseControl, Hudson gibi araçlardan biriyle, push sırasında build alan ve derleme ya da test başarısız olursa ekibe e-posta gönderen bir build sunucusu kurdum
      Tecrübeli geliştiricilerin “Bizim IT’ci böyle bir şeyi nereden biliyor?” diye sorması oldukça eğlenceliydi; DevOps terimi ortaya çıkmadan önce bu rolü kendi kendime yaratabilmiştim. Bunların hepsi boş zamanlarımda Mozilla ile uğraşarak öğrendiklerim sayesindeydi
      Sonuç olarak Mozilla projesini hack’lemenin pratik deneyim kazanmak için iyi bir yol olduğuna tamamen katılıyorum

  • Sonunda düzeltilmiş. Mozilla’nın böyle şeyleri daha fazla yapmasını isterim
    Bu hatanın en sinir bozucu biçimlerinden biri, tam ekran oyun çalıştırırken farenin yeniden konumlandırılmasıyla bir tooltip çıkması ve bunun oyunun üstünde kalmasıydı
    Oyun, Firefox’u ele almak için odağı kaybedip Alt-Tab yapmaktan hoşlanmadığından, sonunda oyunu yeniden başlatmanız gerekebiliyordu

    • Tam da şu anda Jonathan Blow’un 4 yıl önce DevGAMM’de yaptığı sunumu dinliyorum; bu tür kusurlar tekrarlayan bir motif olarak geçiyor
      https://www.youtube.com/watch?v=ZSRHeXYDLko&t=2729s
    • Hâlâ temel container tab davranışının düzeltilmesini bekliyorum. Ürün yönetiminin tamamen bozulmuş olabileceğini düşünmeden edemiyor insan
      [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1479858
    • Birkaç yıl önce hataya “bende de oluyor ve elimde şu bilgiler var” tarzında yorum yaptığımı hatırlıyorum
      Sonunda yaklaşık 10 yıl önce Firefox kullanmayı tamamen bıraktım; ana neden, bu hatanın yıllarca günde birkaç kez canımı sıkması ve o sıralar Chrome’un alternatif olmak için yeterince iyi hale gelmesiydi
      Tooltip içeriği de çoğu zaman “Previous” gibi oldukça genel şeyler oluyordu; nereden geldiğini anlamak için neredeyse tüm Firefox pencerelerine tekrar odak vermem gerekiyordu ve o tooltip kaybolana kadar onu aramak her zaman eziyetti. Üstelik tüm pencerelerin üstünde duruyordu

  • Aradan geçen yıllar boyunca bu davranışın tesadüfen bile değişmemiş olması daha da şaşırtıcı. Etkileyici bir hata geriye dönük uyumluluğu örneği

  • Bu hatayı hep çeşitli Linux masaüstü pencere yöneticilerine yüklüyordum; suçlunun hep aynı olduğunu şimdi öğrendim
    Küçük ekranlarda formları veya diğer önemli öğeleri kapatabildiği için epey can sıkıcı olabiliyordu
    Güncellemeyi dört gözle bekliyorum; umarım Firefox önümüzdeki 22 yıl boyunca yalnızca hatasız olmakla kalmaz, eskiden olduğu gibi etkili bir uygulama haline de gelir

    • Yine de pencere yöneticilerini suçlamaya devam edeceğim gibi. Firefox dışında da, hatta Linux dışında bile kesinlikle gördüm
    • Windows’ta da oluyordu ve işletim sistemleri genelinde başka uygulamalarda da hâlâ oluyor. Tek bir bileşeni ya da GUI katmanını suçlayamayız
    • LibreOffice’te de gördüğümü sanıyorum
    • Başka yerlerde de oluyor. DBeaver’da sık görüyorum
    • Fedora/GNOME/X.Org üzerindeki Chrome’da da düzenli olarak yaşıyorum

  • https://phabricator.services.mozilla.com/rMOZILLACENTRAL8ae3...
    Bu hatayı düzelten beş satırlık değişikliği görüp “Bunu ben de yapabilirdim!” diye düşünüyorsanız, gerçekten yapabilirdiniz
    Asıl soru şu: “Neden yapmadım?”
    Kendi adıma cevap verecek olursam, mesele Firefox’u derlemenin ve test paketini çalıştırmanın ne kadar kolay olduğu
    Ondan sonraki uzun hata takip süreci işin eğlenceli kısmı

    • Düzenli kullandığım yazılımlara sık sık katkıda bulunuyorum ve Firefox için de bir şeyler yapmaya çalışmıştım, ama dışarıdan biri için fazla zor olduğundan vazgeçtim
      hg, birden fazla depo, eski wiki’ler, çok karmaşık bir build süreci, Bugzilla derken tüm sistemin içine girmek çok zor
      Firefox GitHub’da, ya da en azından kendi barındırdığı bir GitLab’da olsaydı; sadece fork edip kurcalayabilsem ve aynı CI’ı çalıştırabilseydim, hikâye bambaşka olurdu. Keşke bu kadar kolay olsaydı
    • Bu düzeltmenin hafife alındığını düşünüyorum. Açıkçası epey satır silinmiş; o satırların aslında ne yapmaya çalıştığını derinlemesine anlamadan Delete tuşuna basmaya cesaret edemezdim
    • Asıl düzeltme bundan da basit görünüyor. Gerçekten yalnızca şu kontrol eklenmiş: !doc->HasFocus(IgnoreErrors())

  • Vay, hep bir şekilde sorunun bende olduğunu sanıyordum. Farklı Windows sürümleri ve yeniden kurulumlar boyunca yıllarca peşimi bırakmadı
    Çok sık olmuyordu ama akılda kalacak kadar düzenli gerçekleşiyordu

    • Yerel olmayan UI toolkit’lerinin hepsinde tooltip davranışı çok ince biçimde hatalıymış gibi geliyor
    • Mozilla son 22 yılda takılı kalan tooltip’lerde reklam alanı satsaydı acaba ne kadar para kazanırdı. Başkası yapmadan kendi hatalarını paraya çevirmeleri gerekirdi
    • Aynen. Delirdiğimi ya da bozuk bir kurulum kullandığımı sanıyordum
    • Bende de öyleydi. Sadece bende oluyor sanıyordum ama Linux ve Windows’taki tüm makinelerimde oluyordu
    • macOS’ta da en az birkaç yıldır aynıydı

  • Oldukça ilginç bir hata. Görünüşe göre birçok kişi yaşamış, hatta bazıları günde en az bir kez gördüğünü söylüyor; ama son 15 yılda bu davranışı bir kez bile gördüğümü hatırlamıyorum
    İşletim sistemiyle sınırlı gibi de görünmediğinden, bu hatanın ortaya çıkmasını sağlayan koşulların gerçekte ne olduğunu merak ediyorum
    Benzer bir hatayı gördüğüm tek yer LibreWolf’tu; yani gizliliği güçlendirilmiş özelleştirilmiş Firefox. Ama bunun tarayıcının kendisinden ziyade flatpak yüzünden olduğundan neredeyse eminim. Çalıştırdığım diğer Firefox’larda böyle bir davranış hiç görmedim

    • Bu tür hatalar birçok GUI sisteminde yeterince yaygın görünüyor. Örneğin Windows 10 görev çubuğunda bu davranışı çok gördüm; kurtulmanın tek yolu imleci çoklu pencere düğmesinin üzerine getirip sonra görev çubuğunun dışına çıkarmaktı
      Birçok web sitesinde de koşullar uygun olduğunda benzer sorunlar oluşuyor
      Ana neden olay iletimi tutarsızlığı gibi görünüyor. İmleç dışarı çıktığında bir olay alması gerekiyor, ama örneğin pencere odağı kaybettiği için artık fare olayları iletilmiyor ve bir şekilde o olay alınamıyor
      Bu tür durumları güvenilir şekilde algılayan özel bir yöntem, örneğin DOM onmouseleave ya da onmouseout gibi bir şey yoksa, geçici çözümler ve hack’ler gerekiyor. Örneğin pencere odağı kaybettiğinde sentetik bir olay üretilebilir
    • Linux KDE Plasma’da OpenSuse Tumbleweed’e yerel olarak kurup kullanıyorum; her gün görüyorum, çoğu zaman da günde birkaç kez
      En iyi şöyle açıklayabilirim: Tooltip’in belirdiği tam o frame’de klavye kısayoluyla başka bir sanal masaüstüne geçtiğimde oluyor
      Çok hassas zamanlama gerektiren bir yarış durumuymuş ve bu yüzden daraltıp bulması zor olmuş olabilir. Çoğunlukla klavye kısayollarını çok kullananlara denk geldiğinden birçok kişi etkilenmemiş olabilir
      Düzeltildiğine gerçekten sevindim ve Firefox’un o sürümünü almayı dört gözle bekliyorum
      Az önce test ettim; yeniden üretmek için fareyi tooltip hedefinin üzerine getirip popup çıkmadan önce, Firefox yeni etkin uygulama değilken başka bir sanal masaüstüne geçmek yeterli
    • Çok iş akışına özgü bir hata. Neredeyse yalnızca video oyunu oynarken yaşıyorum
      Oyun sırasında çoğu zaman bir tarayıcı sekmesinde YouTube videosu açık oluyor, başka bir sekmede de oyunla ilgili bilgi arıyorum
      Bu yüzden oyuna Alt-Tab yapmadan hemen önce sekme çubuğuyla etkileşime girmem sık oluyor ve o sırada tooltip tetikleniyor
      Günlük tarayıcı kullanımında imleç neredeyse her zaman web sitesi içeriğinin üzerinde oluyor; orada tooltip’ler nadiren ortaya çıkıyor
    • Başka web sayfalarına gömülü YouTube videolarıyla etkileşirken bu hatayı sık yaşadım
      Akış şöyle: Gömülü oynatıcının tam ekran kontrolünün üzerine imleci getirince “Full screen (f)” tooltip’i çıkıyor; kontrole tıklayınca video tam ekran oluyor ama tooltip oynayan videonun üzerinde kalmaya devam ediyor
      Linux X11’de MATE’in Marco pencere yöneticisini kullanıyordum
    • Oyunlarda da benzer. “Bozuk” oyunlarıyla ünlü bir stüdyonun oyunu çıkınca insanlar tuhaf şeylerin olduğu derlemeler paylaşıyor, ama bende hiç böyle şeyler olmuyor. Doğuştan gelen bir hata direncim olabilir
      Yine de yer imleri araç çubuğundaki genişletme menüsünü, yani sağ üstteki >> simgesini açınca araç çubuğunda gösterilmeyen yer imleri yerine tüm yer imlerinin açılır listede görünmesi gibi zararsız bir hatayı sık yaşıyorum

  • İlginçtir, bu hata Firefox’un ilk sürümü çıkmadan önce kaydedilmiş: https://en.wikipedia.org/wiki/Firefox_early_version_history
    Hata takip kaydını bu kadar uzun süre çalışır halde tutmaları etkileyici

    • Hata takip kaydı Phoenix/Firebird dönemlerinden beri devam ediyor olabilir

  • Oh, sonunda. İlgili hata olan https://bugzilla.mozilla.org/show_bug.cgi?id=1569439 9 ay önce kapatılmıştı ve bu sayede biraz daha iyi olmuştu
    O hata, yalnızca başka bir uygulamaya geçerken araç ipucunun kaybolmaması sorunuydu. Ama başka bir çalışma alanına geçerken hâlâ kalıyordu, bu da çok hayal kırıklığı yaratmıştı
    Dezavantajı, bunun bir ölçüde “yanlış” bir düzeltme olması. Araç ipuçları, pencere odakta olmasa da görünmelidir. En azından Linux’taki GTK uygulamalarında böyle ve Firefox da bu davranışı taklit etmeye çalışıyor
    Çalışma alanı değiştiği için fare imleci artık gerçekten pencerenin üzerinde olmadığında araç ipucunun kaybolmamasına yol açan temel nedeni düzeltmek gerekiyor

    • Benim en sık karşılaştığım TFA’daki hata değil, o ilgili hataydı. Bir süredir görmüyordum; şimdi nedenini anladım

  • Yamaya doğrudan bağlantı: https://hg.mozilla.org/mozilla-central/rev/8ae372dc88d1

    • Bu bir commit mi?
      Öyleyse girinti değişikliklerini gerçek kod değişiklikleriyle aynı commit’e koymak yaygın mı?
      Şahsen önce girinti değişikliğini commit’ler, ardından ikinci bir commit’te kod değişikliğini yapardım
    • Vay, commit’te girinti değişiklikleri yüzünden değişmiş satırları hariç tutarsak bu değişiklikte yalnızca beş satır yeni kod varmış!