1 पॉइंट द्वारा GN⁺ 2023-10-11 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Firefox के background में होने पर भी tooltip foreground में रह जाने वाला tooltip-ghost bug Bugzilla में लंबे समय तक track किया गया, और Firefox 119 branch में VERIFIED FIXED status पर पहुंचा
  • शुरुआती reproduction toolbar link या icon पर mouse hover कर tooltip दिखाने के बाद Command-Tab या Alt-Tab से किसी दूसरे app पर switch करने पर tooltip के गायब न होने के तरीके से था
  • Mac OS X, Windows, Linux के साथ-साथ Thunderbird, Sunbird, Lightning में भी मिलते-जुलते मामले आते रहे, और Firefox 5.0.1 में तो background window के ऊपर से mouse गुजरने भर से tooltip और mouseover state trigger हो जाती थी
  • final patch only show tooltip when document has focus था, जिसमें document पर focus होने पर ही tooltip दिखाने के लिए बदलाव किया गया, और इसे mozilla-central में 8ae372dc88d1 revision के रूप में शामिल किया गया
  • QA ने Firefox 106.0.1 और Ubuntu 22.04 पर मूल procedure से reproduce करने के बाद Nightly 120.0a1 configuration में पुष्टि की कि समस्या जारी नहीं रही, और बाद में कुछ संबंधित regression bugs अलग से link किए गए

Background Firefox के ऊपर रह जाने वाला tooltip

  • Bug 148624 Firefox के background में होने पर भी tooltip के foreground में रह जाने की समस्या से जुड़ा है
  • मूल title Tooltips persist in foreground when Firefox is in background है, और alias tooltip-ghost है
  • status VERIFIED FIXED है, target milestone 119 Branch है
  • classification Core :: XUL, type defect, severity S3 है

पहली reproduction steps और expected behavior

  • शुरुआती report environment Mozilla/5.0 ... Mac OS X ... Gecko/20020602 BuildID: 2002060203 था
  • reproduce करने की steps सरल थीं
    • toolbar icon या link पर mouse hover करें
    • tooltip आने तक wait करें
    • Command-Tab से Mozilla को background में भेजें
  • असल में छोटा पीला tooltip box foreground में लगातार बना रहा
  • expected behavior यह था कि Mozilla के background में switch होते समय tooltip गायब हो जाए
  • मूल reporter ने लिखा कि tooltip तभी गायब होता था जब Firefox को फिर से foreground में लाकर mouse को toolbar से बाहर ले जाया जाता था

कई platforms पर जारी reproduction cases

  • शुरुआती confirmation के बाद platform scope Mac OS X से All में बदल गया, और Windows XP व Windows 98 पर भी वही समस्या reproduce हुई
  • 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, Firefox 117.0 आदि में भी cases आते रहे
  • Thunderbird, Sunbird और Lightning environments में भी मिलती-जुलती घटना दिखी
    • Thunderbird 2.0.0.17 और Lightning 0.9 में task window tooltip के notification window के ऊपर रह जाने का case attach किया गया
    • Thunderbird 102.4.1 और Firefox 106.0.1 combination में भी GNU/Linux पर reproduce हुआ
    • Firefox 117.0 और Thunderbird 115.2.0, xfce और xfwm environment में भी reproduction steps submit की गईं
  • एक user ने कहा कि Firefox 115.0.2 और GNOME 44 में यह लगातार हो रहा है, और workaround के तौर पर browser.chrome.toolbar_tips setting से tooltips को पूरी तरह disable किया

बचे हुए tooltip से आगे का असर

  • सिर्फ पहले से दिखे tooltip का बने रहना ही नहीं, बल्कि Firefox के background में रहने के दौरान mouse के Firefox window के संबंधित area के ऊपर से गुजरने पर नया tooltip दिखने की symptom भी confirm हुई
  • Firefox 5.0.1 में जब Transmission foreground में और Firefox background में था, तब Transmission Inspector window के ऊपर mouse move करने पर Firefox का tooltip trigger होने का case attach किया गया
  • Adblock Plus toolbar button का बड़ा tooltip Transmission के ऊपर दिखने का case भी था
  • Transmission का Options tooltip और Firefox के Google search box का tooltip साथ-साथ दिखकर एक-दूसरे पर overlap होने का case दर्ज है
  • bookmarks toolbar items में tooltip के साथ-साथ mouseover state भी trigger हुई
    • bookmark button की state पहले बदली और थोड़ी देर बाद URL tooltip दिखाई दिया
    • Open a New Tab के + button को भी background state में mouseover state और tooltip पैदा करने वाले exception के तौर पर record किया गया

fix की दिशा और लागू patch

  • 2010 के शुरुआती दशक की discussion में यह approach propose की गई कि tooltip timer चलने पर अगर window में focus न हो, तो tooltip न दिखाया जाए
  • Safari और Google Chrome को Mac पर foreground app न होने पर tooltip न दिखाने वाले comparison cases के रूप में इस्तेमाल किया गया
  • final patch description only show tooltip when document has focus था
  • patch Phabricator attachment के रूप में आया, और बाद में autoland और mozilla-central में शामिल हुआ
  • status ASSIGNED से RESOLVED में बदला, और resolution FIXED हो गया

QA verification और follow-up regressions

  • QA ने Firefox 106.0.1 और Ubuntu 22.04 पर मूल reproduction steps से issue confirm किया
  • उसी configuration में latest Nightly 120.0a1 पर समस्या अब जारी नहीं रही, इसलिए status VERIFIED में बदल गया
  • firefox119 status fixed से verified में बदला
  • एक user ने लिखा कि समस्या केवल MOZ_ENV_XINPUT2=1 होने पर दिखती है और MOZ_ENV_XINPUT2=0 होने पर गायब हो जाती है, और इसे bug 1809029 से link किया गया
  • बाद में संबंधित regressions के रूप में ये bugs link किए गए
    • 1857513: bookmark sidebar tooltip sidebar पर focus न होने पर hover से नहीं दिखता
    • 1861427: किसी दूसरे application के focused होने पर hover करने से tooltip अब नहीं दिखता
    • 2043757: Windows 11 में Firefox के किसी दूसरी window से partly covered होने पर tab title hover से नहीं दिखता

1 टिप्पणियां

 
GN⁺ 2023-10-11
Hacker News की राय
  • अगर आप जानना चाहते हैं कि Firefox codebase में bugs कैसे खोजे और fix किए जाते हैं, तो Mike Conley कई सालों से Mozilla में अपने development work की हर हफ्ते live streaming कर रहे हैं
    रिकॉर्ड किए गए content का बड़ा हिस्सा backlog से एक bug चुनकर उसे बहुत बारीकी से trace करके पकड़ने की प्रक्रिया है
    खासकर अगर आपने अभी-अभी programming शुरू की है और देखना चाहते हैं कि असली codebase में काम करना कैसा होता है, तो यह recommend करूंगा: https://youtube.com/@mikeconleytoronto

    • कॉलेज के दिनों में, लगभग उतने ही पुराने समय से जब यह bug दर्ज हुआ था, मैंने Mozilla में काफी volunteering की थी
      शुरुआत में मैंने QA team में bug triage किया, यह जांचते हुए कि Bugzilla component सही है या नहीं, reproduce करने के steps समझ में आते हैं या नहीं, वगैरह
      मेरे पास practical experience बिल्कुल नहीं था, फिर भी यह देखना ही बहुत सीखने वाला था कि कोई बड़ा project कैसे चलता है और असली developers fixes और features को कैसे handle करते हैं; diff, patch, CI/CD जैसी concepts से भी परिचय हुआ। उस समय nightly build होता था, इसलिए सख्ती से कहें तो continuous integration नहीं था, लेकिन दिशा वही थी
      बाद में मैंने apps build करना सीखा, जो खासकर Windows पर सचमुच मुश्किल था। मैंने Firefox, Thunderbird, और उस समय अभी मौजूद Mozilla Suite तक build किया था, जिसमें browser, mail, HTML editor आदि एक integrated रूप में थे
      आखिरकार मैंने खुद भी कुछ bug fixes contribute किए। वे बस typo या misaligned icon ठीक करने जैसे थे, लेकिन यह अहसास जबरदस्त था कि वह code deploy होगा जिसे लाखों लोग सच में इस्तेमाल करते हैं
      graduation के बाद मेरी पहली नौकरी में यह experience तुरंत काम आया। एक startup में मैंने IT support और QA से शुरुआत की, जहां build और deployment automation बिल्कुल नहीं था। कोई SVN में push कर देता, फिर भी कई दिनों तक पता नहीं चलता था कि build टूट गया है या नहीं
      Mozilla से सीखी बातों के आधार पर मैंने Buildbot, CruiseControl, Hudson में से किसी चीज़ का उपयोग करके एक build server बनाया, जो push होने पर build करता था और compile failure या test failure होने पर team को email भेजता था
      अनुभवी developers का यह पूछना काफी मजेदार था कि “हमारे IT guy को यह सब आखिर कैसे पता है,” और DevOps शब्द आने से पहले ही मैं अपने लिए वैसी भूमिका बना पाया। यह सब खाली समय में Mozilla से छेड़छाड़ करके सीखा था
      इसलिए मैं पूरी तरह सहमत हूं कि Mozilla project को hack करके देखना practical experience हासिल करने का अच्छा तरीका है
  • आखिरकार fix हो गया। काश Mozilla ऐसी चीज़ें और ज्यादा करे
    इस bug के सबसे परेशान करने वाले रूपों में से एक तब होता है जब full-screen game चलाते समय mouse reposition होता है और tooltip दिख जाता है, और वह game के ऊपर float करने लगता है
    game Firefox को handle करने के लिए focus खोना और Alt-Tab होना पसंद नहीं करता, इसलिए कभी-कभी आखिर में game restart करना पड़ता है

    • संयोग से मैं अभी Jonathan Blow की 4 साल पहले DevGAMM में दी गई presentation सुन रहा हूं, जिसमें इस तरह की खामियां बार-बार आने वाले motif की तरह आती हैं
      https://www.youtube.com/watch?v=ZSRHeXYDLko&t=2729s
    • मैं अब भी basic container tab behavior के fix होने का इंतजार कर रहा हूं। यह सोचे बिना नहीं रहा जाता कि product management पूरी तरह टूट चुकी है
      [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1479858
    • मुझे याद है कि कई साल पहले मैंने bug पर इस तरह comment किया था कि “मैं भी इसे face कर रहा हूं और मेरे पास यह जानकारी है”
      आखिरकार लगभग 10 साल पहले मैंने Firefox इस्तेमाल करना पूरी तरह छोड़ दिया, मुख्य वजह यह थी कि यह bug कई सालों तक दिन में कई बार परेशान करता था, और उस समय तक Chrome replacement बनने के लिए काफी अच्छा हो चुका था
      tooltip content भी अक्सर “Previous” जैसा काफी generic होता था, इसलिए यह पता लगाने के लिए कि वह कहां से आया है, लगभग हर Firefox window पर फिर से focus देना पड़ता था, और उस tooltip के गायब होने तक उसे ढूंढते रहना हमेशा कष्टदायक था। ऊपर से वह सभी windows के ऊपर तैरता रहता था
  • इससे भी ज्यादा हैरानी की बात यह है कि इतने सालों में यह behavior संयोग से भी नहीं बदला। प्रभावशाली bug backward compatibility है

  • मैं इस bug का दोष हमेशा अलग-अलग Linux desktop window managers पर डालता था, अब जाकर पता चला कि culprit हमेशा वही था
    छोटी screen पर यह forms या दूसरे महत्वपूर्ण elements के display को ढक सकता था, इसलिए कभी-कभी काफी खीझ पैदा करता था
    update का इंतजार है, और उम्मीद है कि अगले 22 सालों में Firefox सिर्फ bug-free ही नहीं, बल्कि पहले की तरह प्रभावशाली application भी बने

    • फिर भी शायद मैं window manager को दोष देता रहूंगा। Firefox के बाहर भी, यहां तक कि Linux के बाहर भी, मैंने यह पक्का देखा है
    • Windows पर भी हुआ है, और operating systems के पार दूसरे applications में भी लगातार होता है। किसी एक specific component या GUI layer को ही दोष नहीं दिया जा सकता
    • लगता है मैंने इसे LibreOffice में भी देखा है
    • यह दूसरी जगहों पर भी होता है। DBeaver में अक्सर देखा है
    • Fedora/GNOME/X.Org पर Chrome में भी नियमित रूप से इसका सामना करता हूं
  • https://phabricator.services.mozilla.com/rMOZILLACENTRAL8ae3...
    इस बग को ठीक करने वाले पाँच लाइन के बदलाव को देखकर अगर आप सोचते हैं, “यह तो मैं भी कर सकता था!”, तो सच में कर सकते थे
    असली सवाल है, “फिर किया क्यों नहीं?”
    खुद ही जवाब दूँ तो, मामला इस पर निर्भर है कि Firefox को compile करना और test suite चलाना कितना आसान है
    उसके बाद की लंबी bug-tracking प्रक्रिया ही मज़ेदार हिस्सा है

    • मैं रोज़ इस्तेमाल होने वाले software में अक्सर योगदान करता हूँ और Firefox में भी कुछ करने की कोशिश की थी, लेकिन बाहरी लोगों के लिए यह इतना मुश्किल था कि मैंने बस छोड़ दिया
      hg, कई repositories, पुराने wiki, बेहद जटिल build, Bugzilla वगैरह से जुड़ा पूरा system entry के लिए बहुत कठिन है
      अगर Firefox GitHub पर, या कम से कम self-hosted GitLab पर होता, जहाँ बस fork करके चीज़ें आज़माई जा सकतीं और वही CI चलाया जा सकता, तो कहानी बिल्कुल अलग होती। काश यह इतना आसान होता
    • लगता है इस fix को कम आंका गया है। सच कहूँ तो हटाई गई lines काफी हैं, और जब तक मैं गहराई से यह न समझ लेता कि वे lines मूल रूप से क्या करने की कोशिश कर रही थीं, Delete key दबाने की हिम्मत नहीं होती
    • असली fix तो उससे भी ज़्यादा सरल दिखता है। सच में बस यह एक check जोड़ा गया है: !doc->HasFocus(IgnoreErrors())
  • वाह, मैं हमेशा किसी तरह इसे अपनी ही गलती समझता रहा। कई Windows versions और reinstallations के बावजूद यह सालों तक मेरे साथ बना रहा
    यह अक्सर नहीं होता था, लेकिन याद रह जाने लायक नियमित रूप से होता था

    • लगता है non-native UI toolkits में tooltip behavior किसी न किसी बेहद सूक्ष्म तरीके से buggy होता ही है
    • सोचता हूँ Mozilla ने पिछले 22 सालों में अटके हुए tooltip पर ad space बेची होती तो कितना पैसा कमा सकता था। किसी और के करने से पहले उन्हें अपने bug को monetize कर लेना चाहिए था
    • सही। मुझे लगता था मैं पागल हो रहा हूँ, या कोई टूटी हुई installation इस्तेमाल कर रहा हूँ
    • मेरे साथ भी यही था। मुझे लगा सिर्फ मेरे साथ होता है, लेकिन Linux और Windows पर मेरी सभी machines में हुआ
    • macOS पर भी कम से कम कई सालों तक ऐसा ही था
  • काफी दिलचस्प bug है। लगता है बहुत लोगों ने इसे झेला है, और कोई कहता है कि उसे दिन में कम से कम एक बार दिखता है, लेकिन पिछले 15 सालों में मुझे यह behavior एक बार भी दिखा हो, याद नहीं
    यह operating system तक सीमित भी नहीं लगता, इसलिए उत्सुकता है कि असल में वे conditions क्या थीं जिनमें यह bug सामने आता था
    ऐसा मिलता-जुलता bug मैंने सिर्फ LibreWolf में देखा है, यानी privacy को मजबूत करने वाला customized Firefox। लेकिन मुझे लगभग पूरा यकीन है कि वह browser की वजह से नहीं, बल्कि flatpak की वजह से था। मेरे चलाए बाकी Firefox ने कभी ऐसा behavior नहीं दिखाया

    • इस तरह के bug कई GUI systems में काफी आम लगते हैं। उदाहरण के लिए Windows 10 taskbar में मैंने यह behavior बहुत देखा है, और उससे निकलने का इकलौता तरीका cursor को multi-window button पर ले जाकर फिर taskbar से बाहर निकालना था
      कई websites में भी conditions सही हों तो मिलती-जुलती समस्या आ जाती है
      मुख्य कारण event delivery mismatch लगता है। cursor बाहर जाने पर event मिलना चाहिए, लेकिन कभी-कभी नहीं मिलता, जैसे window focus खो देती है और mouse events आगे deliver नहीं होते
      ऐसे cases को भरोसेमंद तरीके से detect करने का कोई dedicated तरीका, जैसे DOM onmouseleave या onmouseout, न हो तो workarounds और hacks चाहिए होते हैं। मसलन window focus खोने पर synthetic event बनाया जा सकता है
    • Linux KDE Plasma पर OpenSuse Tumbleweed में native install करके इस्तेमाल करता हूँ और इसे रोज़ देखता हूँ, ज़्यादातर दिनों में दिन में कई बार
      सबसे अच्छी तरह कहूँ तो यह तब होता है जब tooltip आने वाले ठीक उसी frame में keyboard shortcut से किसी दूसरे virtual desktop पर switch किया जाए
      यह बहुत सटीक timing माँगने वाली race condition थी, इसलिए शायद इसे narrow down करना मुश्किल था। यह ज़्यादातर keyboard shortcuts बहुत इस्तेमाल करने वालों को पकड़ती है, इसलिए संभव है बहुत लोग प्रभावित न हुए हों
      यह ठीक हो गया सुनकर सचमुच खुशी है, और उस version का Firefox मिलने का इंतज़ार है
      अभी test करके देखा, reproduce करने के लिए बस mouse को tooltip target पर रखें और popup आने से पहले, Firefox के नई active application न रहते हुए, किसी दूसरे virtual desktop पर बदल जाएँ
    • यह बहुत workflow-specific bug है। मुझे यह लगभग सिर्फ video games खेलते समय होता है
      game के दौरान अक्सर एक browser tab में YouTube video चलती रहती है, और दूसरे tab में game से जुड़ी जानकारी खोजता हूँ
      इसलिए game में Alt-Tab करने से ठीक पहले tab bar से interact करना आम है, और उसी समय tooltip trigger हो जाता है
      रोज़मर्रा की browser use में cursor लगभग हमेशा website content पर होता है, जहाँ tooltips बहुत कम आते हैं
    • दूसरी webpages में embedded YouTube videos से interact करते समय मैंने यह bug बहुत झेला
      flow ऐसा है। embedded player के full screen control पर cursor ले जाने पर “Full screen (f)” tooltip आता है, और control click करने पर video full screen हो जाता है, लेकिन tooltip चल रहे video के ऊपर वैसा ही रह जाता है
      Linux X11 पर MATE का Marco window manager इस्तेमाल किया था
    • games में भी ऐसा ही है। जब “broken” titles के लिए मशहूर studio का game आता है, लोग अजीब चीज़ों के compilations post करते हैं, लेकिन मेरी तरफ ऐसी चीज़ें बिल्कुल नहीं होतीं। शायद जन्मजात bug resistance है
      हालांकि bookmarks toolbar के overflow menu, यानी ऊपर दाएँ >> icon को खोलने पर toolbar में न दिखने वाले bookmarks के बजाय सभी bookmarks dropdown list में दिखने वाला harmless bug मुझे अक्सर होता है
  • दिलचस्प बात यह है कि यह bug Firefox के पहले version के आने से पहले ही दर्ज हो गया था: https://en.wikipedia.org/wiki/Firefox_early_version_history
    bug tracker history को इतने लंबे समय तक काम करते रखना प्रभावशाली है

    • हो सकता है bug tracker history Phoenix/Firebird के दौर से चली आ रही हो
  • ओह, आखिरकार। इससे संबंधित bug https://bugzilla.mozilla.org/show_bug.cgi?id=1569439 9 महीने पहले बंद हो गया था, और उसकी वजह से स्थिति थोड़ी बेहतर हुई थी
    वह bug बस इतना था कि दूसरी app पर switch करने पर tooltip गायब नहीं होता था। लेकिन दूसरे workspace पर switch करने पर वह अब भी बना रहता था, इसलिए बहुत निराशा हुई थी
    कमी यह है कि यह कुछ हद तक “गलत” fix है। tooltip को window पर focus न होने पर भी दिखना चाहिए। कम से कम Linux के GTK apps में ऐसा ही होता है, और Firefox भी उसी व्यवहार की नकल करने की कोशिश करता है
    मूल कारण को ठीक करना चाहिए कि workspace बदल जाने पर, जब mouse pointer असल में अब window के ऊपर नहीं रहता, तब tooltip गायब क्यों नहीं होता

    • मुझे सबसे ज्यादा TFA वाला bug नहीं, बल्कि उससे संबंधित bug झेलना पड़ा था। कुछ समय से वह नहीं दिखा था, अब वजह समझ आई
  • patch का direct link: https://hg.mozilla.org/mozilla-central/rev/8ae372dc88d1

    • क्या यह commit है?
      अगर हाँ, तो क्या indentation change और असली code change को एक ही commit में रखना आम बात है?
      निजी तौर पर तो मैं पहले indentation change commit करता, फिर दूसरे commit में code change करता
    • वाह, commit में indentation change की वजह से बदली हुई lines को छोड़ दें, तो इस change में नया code सिर्फ पाँच lines का है!