25 साल बाद ठीक किया गया Firefox <textarea> बग

 (bugzilla.mozilla.org)
1 पॉइंट द्वारा GN⁺ 2024-05-23 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Firefox का पुराना Bug 33654 एक ऐसी समस्या थी जिसमें <textarea> पर ROWS= और COLS= लागू करते समय scrollbar की जगह भी जोड़ दी जाती थी, जिससे वह तय की गई rows और columns से बड़ा दिखता था; अब इसे Bug 1830576 का duplicate मानकर बंद कर दिया गया है
  • जिन environments में overlay scrollbars बंद हैं या “always show scrollbars” setting इस्तेमाल होती है, वहाँ <textarea rows=N> की ऊँचाई लगभग N+1 rows के रूप में calculate होने की समस्या बार-बार दिखी
  • शुरुआती चर्चा font inheritance, जबरन monospace लागू करने, w और W की average width के आधार पर cols calculation, और scrollbar space reserve करने के तरीके तक फैली; लंबे समय तक test cases, patches और screenshots जमा होते रहे
  • असल में rows=1 3 rows जैसा दिखता था या rows=2 3 rows ऊँचा दिखता था, और cols=80 पर IE और Firefox में line wrap की position अलग होती थी, यानी form layout control browsers के बीच असंगत था
  • Bug 1830576 के VERIFIED FIXED होने के बाद WebKit, Chromium और Firefox में scrollbar spacing लागू करने का व्यवहार consistent हो गया, और Bug 33654 को RESOLVED DUPLICATE के रूप में बंद कर दिया गया

Bug 33654 की स्थिति और scope

  • Bug 33654 <textarea> द्वारा ROWS= और COLS= को गलत तरीके से लागू करने से जुड़ा defect था, जिसमें overlay scrollbars disabled होने पर horizontal और vertical scrollbars के लिए extra space बन जाती थी
  • Product और component Core :: Layout: Form Controls हैं, और इसमें HTML form controls का layout और appearance, खासकर textarea जैसे elements, शामिल हैं
  • मौजूदा स्थिति RESOLVED DUPLICATE of bug 1830576 है
    • Duplicate target Bug 1830576 का title है Firefox sizes <textarea rows=N> as roughly N+1 rows tall, under an "always show scrollbars" configuration
    • Bug 1830576 की स्थिति VERIFIED FIXED है
  • यह bug 26 साल पहले खोला गया था, और 2 साल पहले RESOLVED DUPLICATE के रूप में बंद हुआ
  • Metadata में version Trunk, platform x86 / All, type defect, priority P3, और severity S3 दिखते हैं
  • Keyword testcase है, Whiteboard [html][behavior]relnote-devel है, और votes की संख्या 99 दिखती है
  • Attachments 17 files, 17 obsolete files के रूप में दिखते हैं, और test cases, patches और screenshots बार-बार upload किए गए

पहली बार दिखे symptoms

  • शुरुआती report में Andrew McMillan ने लिखा कि ROWS=5 COLS=30 से set किया गया TEXTAREA example लगभग ROWS=7 COLS=48 जैसा display होता है
  • शुरुआती comments में ऐसे cases जारी रहे जहाँ INPUT TYPE=TEXT और TEXTAREA specified font को ठीक से use नहीं कर रहे थे, या scrollbar दिखने पर भी area बहुत ऊँचा था
  • बाद की चर्चा इस ओर गई कि textarea layout को गलत information मिल रही है, columns में extra space है और rows एक ज्यादा हैं
  • Scrollbar के लिए पहले से जगह reserve करने का तरीका कारण हो सकता है, यह possibility भी शुरुआत में discuss की गई

Font calculation और शुरुआती patch

  • HTML authoring newsgroup के case में textarea { font-size: 8pt } और <textarea cols="40" rows="12"> को साथ इस्तेमाल करने पर IE width सही render करता था, लेकिन Mozilla ऐसा दिखता था जैसे वह 12pt font के आधार पर width calculate कर रहा हो
  • arial font इस्तेमाल करने वाली test file में <textarea NAME=system_code wrap=soft rows=5 cols=30 WRAP style="font-family:arial"> शामिल था
  • Rod का मानना था कि default font में size calculation सही है, इसलिए core issue sizing नहीं बल्कि textarea द्वारा सही font use न करना है
  • Kin ने पाया कि जब editor का PlainText flag set होता है, तो TextControl के content area पर font-family: monospace; forcibly apply करने वाला code मौजूद है
    • इस code को हटाने पर सही font use होता है
    • लेकिन NavQuirks mode में 30-column textarea के अंदर 30-character string width का सिर्फ लगभग 2/3 हिस्सा ही लेती है
    • वजह के तौर पर यह तरीका बताया गया कि nsFormControlHelper font से w और W की average width निकालकर उसे column count से multiply करता है और scrollbar width जोड़कर textarea width calculate करता है
  • Patch to use the correct font. ने plain text editor initialization flags में eEditorEnableWrapHackMask जोड़ा और font-family: monospace; लागू करने को conditional बनाया
  • इस patch को एक समय RESOLVED FIXED के रूप में mark किया गया था, लेकिन original reporter ने बताया कि COLS=... सही होने पर भी ROWS=... अब भी गलत behave कर रहा है, इसलिए इसे फिर से reopen किया गया

बार-बार reproduction और duplicate bugs

  • Duplicate bug list में कई issues शामिल थे जहाँ <textarea> specified rows से एक line ज्यादा बड़ा दिखता था या rows=1 3 lines जैसा दिखता था
    • 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 एक HTML 4.01 Strict document था जिसमें buttons से rows और cols values बदली जा सकती थीं, और font tag या variable-width font इस्तेमाल नहीं किया गया था
    • Behavior में specified value से हमेशा 3 columns ज्यादा और आमतौर पर 1 row ज्यादा दिखती थी
    • rows=1 request करने पर 3 rows display होती थीं
  • 2002 के Linux और Win2000 trunk builds में <textarea cols=40 rows=2></textarea> 3 rows में display होता था, और rows=N होने पर ठीक N+1 rows display होने के cases सामने आए
  • W3C HTML 4.01 test को भी reference material के रूप में इस्तेमाल किया गया, और comments में लिखा गया कि ROWS related test में समस्या साफ दिखती है
  • Windows 2000 और Mozilla 0.9.3 पर भी ऐसा example upload हुआ जिसमें rows=1 textarea स्पष्ट रूप से 1 row जैसा नहीं दिखता था

Scrollbar space calculation पर चर्चा

  • Comment 86 ने समझाया कि textarea size specified cols/rows में scrollbar space जोड़कर calculate होता है
  • Analysis में कहा गया कि IE के उलट Mozilla scrollbar को सिर्फ जरूरत पड़ने पर display करता है, इसलिए users को यह broken behavior लगता है
  • Possible choices के तौर पर तीन options suggest किए गए
    • textarea size calculate करते समय scrollbar size न जोड़ना
    • IE की तरह scrollbar हमेशा display करना
    • सिर्फ display होने वाले scrollbar को include करना
  • तीसरे option पर objection था कि size scrollbar दिखने या न दिखने पर depend करेगा, और scrollbar दिखेगा या नहीं यह फिर size पर depend करेगा, जिससे circular dependency बनती है
  • Comment 87 ने चौथे option के रूप में suggest किया कि ROWS और COLS सिर्फ textarea content size control करें, और scrollbar दिखने पर textarea बड़ा हो जाए
  • इसके बाद implementation direction पर चर्चा हुई कि पहले scrollbar के बिना width/height से reflow करके scrollbar की जरूरत तय की जाए, फिर जरूरत होने पर नई width/height से दोबारा reflow किया जाए

Users पर दिखा असर

  • अगर rows="2" set करने पर 3-row height वाला textarea दिखे, तो intended visual guidance कमजोर पड़ जाती है
    • एक web application short summary text मांगते हुए rows="2" इस्तेमाल करती थी ताकि “एक line से ज्यादा लेकिन essay नहीं” जितना input संकेतित हो
    • Firefox और IE6, Opera 8 के behavior differences की वजह से वही rows value user agents में अलग visual guidance देती थी
  • Comments में कहा गया कि textarea content scroll न होने पर भी Firefox behavior गलत है
    • Address input जैसे textarea, जो ज्यादातर तीन lines से ज्यादा नहीं होंगे, उनमें rows="3" set करने पर भी Firefox हमेशा extra row display करता था
    • Page अनावश्यक रूप से बड़ी हो जाती थी, और user box उम्मीद से बड़ा देखकर सोच सकता था कि उसने पर्याप्त information नहीं भरी है
  • cols=80 comparison में screenshot description था कि IE 80 1 characters को scrollbar edge तक भरने के बाद line wrap करता है, लेकिन Firefox में 80 1 के बाद भी 2 और characters की जगह रहती है और उसके बाद horizontal scrollbar दिखता है
  • 2019 में भी समस्या बाकी होने का comment था, और Discord का Chat bar is a line taller than usual on Firefox Trello card impact case के रूप में पेश किया गया

लंबे समय तक चले patch attempts

  • Hideo Saito ने कई बार patches और test cases attach किए
    • patch for rows and cols
    • wrap="off" patch testcase
    • base patch
    • additional patch for another bug
    • patch which does not remove space
  • एक approach में nsTextControlFrame::Reflow को scrollbars को छोड़कर intrinsic size से perform किया गया, फिर scrollbar होने पर intrinsic size में scrollbar size जोड़कर दोबारा reflow किया गया
  • GetScrollbarStyles को modify करके text control frame यह control करे कि scrollbar को auto, hidden, scroll में से क्या रखा जाए, इस approach पर भी चर्चा हुई
  • roc ने nsGfxScrollFrame में ज्यादा changes डालने के बजाय nsTextControlFrame में handle करने का तरीका prefer किया
  • बाद के patches में SetScrollbarStyles, GetScrollbarStyles, SetScrollbarSpace, GetScrollbarOverflowState, FrameNeedsReflow, post-reflow callback जैसे mechanisms पर review और rework दोहराया गया
  • कुछ patches को review- मिला या obsolete mark किया गया, और reviewer ने बताया कि trunk के अनुसार update की जरूरत है

Temporary workarounds और limitations

  • Suggestion था कि CSS textarea{ overflow-x: hidden } जोड़ने से issue solve हो जाता है
  • इस method पर condition थी कि यह सिर्फ तब लागू होता है जब horizontal scrollbar की जरूरत न हो
  • एक अन्य comment ने counter किया कि यह bug सिर्फ CSS overflow से fix नहीं किया जा सकता, और Firefox ही एकमात्र browser है जो textarea render करते समय एक line extra जोड़ता है
  • Emilio Cobos Álvarez ने कहा कि वजह scrollbar size लगती है और <textarea> पर scrollbar-width: none apply करने से issue solve होता दिखता है
  • उसी comment में यह भी जोड़ा गया कि फिर भी bug को खुद fix किया जाना चाहिए

अंतिम निष्कर्ष

  • 3 साल पहले BugBot ने कहा कि इस bug की severity अपेक्षाकृत low S3 है, लेकिन इसके 27 duplicates, 103 votes और 91 CC हैं, इसलिए severity बढ़ाने पर विचार करने को कहा
  • Bug summary 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 को dependency के रूप में add किया
  • Luke Warlow ने पूछा कि चूँकि Bug 1830576 fix हो चुका है, WebKit, Chromium और Firefox में scrollbar spacing apply करना consistent हो गया है, क्या इस bug को बंद किया जा सकता है
  • Emilio Cobos Álvarez ने इससे सहमति जताई, और Bug 33654 NEW से RESOLVED में बदल गया तथा DUPLICATE के रूप में बंद हुआ
  • Duplicate target Bug 1830576 set किया गया, और वह bug VERIFIED FIXED स्थिति में है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-05-23
Hacker News की राय

  • हा! उन 25 सालों में से ज़्यादातर समय मैं इस bug को subscribe किए हुए था। उस समय Firefox था ही नहीं, और यह Netscape Navigator नहीं बल्कि उसके आसपास के दौर के Mozilla side का bug दर्ज हुआ था
    याद नहीं कि मैंने subscribe क्यों किया था, शायद comment किया होगा। हर कुछ सालों में एक notification mail आ जाता था और हमेशा हंसी आती थी, लेकिन कुछ दिन पहले आखिरकार यह ठीक हो गया

    • हैरानी की बात है कि उस bug thread की subscription इतने लंबे समय तक बची रही
    • मेरे साथ भी कुछ ऐसा ही है। जब मैं पहली बार सोच रहा था कि क्या website बनाना पेशे के तौर पर करूं, तब मुझे ऐसी websites की कल्पना ने मोहित किया था जिनका background desktop तक transparent या translucent दिखे
      मैं हमेशा सोचता था कि html { background: transparent; } जैसा कुछ लिखने पर यह बस काम करना चाहिए। हालांकि यह bug fix असल में वह नहीं करता। पहले तो यह कोई feature नहीं है जिसे websites default तौर पर चुनें, बल्कि एक setting है जिसे user या extension चालू कर सकता है। शायद यही बेहतर है, क्योंकि default allow होने पर clickjacking का नया रास्ता खुल जाता
    • “Netscape Navigator के लिए दर्ज किया गया” कहने के बजाय यह Mozilla Suite side का था। 2000 तक Mozilla era में काफी आगे आ चुके थे, और मुझे नहीं लगता कि Netscape bugs Bugzilla में आए होंगे
    • वाह, यह bug तो खुद Firefox से भी पुराना है
    • अगला नंबर Jira के projects के बीच version tickets के solve होने का है

  • विषय से थोड़ा हटकर, लेकिन “एक महीने पहले” जैसे human-readable duration display के trend से मुझे सच में नफरत है। बस date दिखा दो, मैं खुद हिसाब लगा सकता हूं
    Outlook, कम से कम Mac version, सबसे खराब है। आज से पहले के mails, उदाहरण के लिए, सिर्फ “कल” दिखते हैं, और time देखने के लिए mail पर click करना पड़ता है। एक दिन में दर्जनों mails आते हैं, ऐसे में अगर 50 messages लगातार सिर्फ “कल” दिखें तो उसका कोई उपयोग नहीं

    • अच्छा हो अगर human-readable display पर mouse hover करने से exact timestamp दिखे
    • सच में चाहता हूं कि यह trend जल्दी खत्म हो। mail उस दिन सुबह 6 बजे आया था या रात 11 बजे, इसमें बहुत बड़ा फर्क है। सिर्फ “कल” कहना काफी नहीं है
      beer ठंडी हो, timestamps exact हों—यही अच्छा है
    • अगर यह गलत भी हो तो और भी बुरा। Discogs October 2021 को “3 साल से भी ज़्यादा पहले” बताने पर अड़ा है
    • “बस date दिखा दो, मैं खुद हिसाब लगा सकता हूं” मेरे लिए सच में मुश्किल है। मुझे dates या समय के प्रवाह की अवधारणा से ही काफी दिक्कत होती है
    • date पर mouse hover करने से exact date और time दिखता है

  • Firefox का Bugzilla निश्चित रूप से सबसे लंबे समय से चल रहे bug trackers में से एक है। इतनी सारी revisions से गुज़रने के बावजूद उसमें original feel काफी बची हुई है, यह प्रभावशाली है। पहले यह काफी rough और monster जैसी codebase थी
    2000 के आसपास Windows development organization में Microsoft Access/Outlook आधारित अपने custom bug tracker को replace करने के लिए हमने एक instance खड़ा किया था। complex था, लेकिन कुछ समय तक लगभग best-in-class bug tracker था। FogBugz भी उसी दौर में बस शुरू हो रहा था, और मेरे हिसाब से वह team user experience को गंभीरता से लेने वाली शुरुआती teams में से एक थी

    • आज भी Bugzilla को पछाड़ना आसान नहीं है। सच कहें तो आज के कुछ विकल्प Bugzilla से इतने खराब हैं कि समझ नहीं आता वे मौजूद कैसे हैं। उदाहरण के लिए Dwarf Fortress द्वारा इस्तेमाल किया जाने वाला Mantis BT सच में घटिया है
      इसके उलट FogBugz एक ऐसा tool है जिसे मौका मिलने पर मैं हमेशा आज़माना चाहता था

  • ऐसी चीज़ें देखकर दिल गर्म हो जाता है। हाल ही में मेरे साथ भी 24 साल पुराने Firefox bug में कुछ ऐसा ही हुआ: https://bugzilla.mozilla.org/show_bug.cgi?id=62151

    • धत्त, याद है मैं इसकी वजह से अटककर भटकता रहा था

  • लंबे समय से unresolved bugs में सबसे परेशान करने वाली बात यह है कि LibreOffice में scatter plot के x-axis को ठीक से date format में specify नहीं किया जा सकता
    https://bugs.documentfoundation.org/show_bug.cgi?id=54132
    यह 12 साल पुराना bug है। comments देखें तो माहौल ऐसा है कि code इतना “डरावना complex” है कि इसे fix करने पर regression आने की संभावना बड़ी है, इसलिए लोग fix करने से हिचक रहे हैं

    • मैं चाहता था कि LibreOffice, Excel के वे features ले आए जो मुझे पसंद हैं, लेकिन यह देखकर उम्मीद कम हो गई
    • अगर सिर्फ spreadsheet और graphing package चाहिए, तो Linux पर gnumeric अच्छा विकल्प है
    • अच्छा लगता है जब maintainers उस code से डरने लगते हैं जिसे उन्होंने खुद merge होने दिया था

  • अगली बार उम्मीद है XDG कर देंगे। इसका भी 20 साल से इंतज़ार चल रहा है [1]
    [1] https://bugzilla.mozilla.org/show_bug.cgi?id=259356

    • मुझे नहीं लगता कि XDG बेस डायरेक्टरीज़ कभी पूरी तरह और सार्वभौमिक रूप से अपनाई जाएँगी। पहले ही 21 साल हो चुके हैं। अगर Arch Linux उन प्रोग्रामों के प्रति आक्रामक न होता जो इसका पालन नहीं करते—मसलन root user directory permissions लॉक करने जैसे तरीकों से—तो यह हाल के वर्षों में इतना बड़ा भी नहीं हुआ होता
      सच कहूँ तो यह specification लोगों की असली समस्याओं को सक्रिय रूप से हल नहीं करती। अपनाया जाना ज़्यादातर उन लोगों का नतीजा है जिन्हें $HOME directory की बनावट खटकती थी और जिन्होंने maintainers को परेशान कर-करके दबाव डाला; 99% users को फ़र्क नहीं पड़ता कि कोई program XDG बेस डायरेक्टरीज़ का पालन करता है या नहीं। यह बस 20 साल से ज़्यादा समय तक व्यापक रूप से न अपनाई गई freedesktop specification के आधार पर “ज़्यादा साफ-सुथरा” होने का दावा करने लायक बनाता है
      निजी तौर पर मुझे वह ढीला-ढाला config/data/cache विभाजन और implicit intent पसंद नहीं है। हर चीज़ उन categories में फिट नहीं बैठती, और इससे system behavior predict करना मुश्किल हो जाता है। क्या कोई daemon मेरा cache साफ़ कर देगा? क्या user settings folder को कॉपी करके इधर-उधर ले जाएगा? आखिर backup में ठीक-ठीक क्या जाएगा? specification में folders को वास्तव में कैसे treat किया जाना चाहिए, इसका कोई standard नहीं है। यह जानबूझकर अस्पष्ट है, लेकिन ऐसी तरह से अस्पष्ट है कि लोग assumptions बनाएँ तो चीज़ें टूट सकती हैं
      यह root से /usr अलग करने, root से /usr/local अलग करने, या /opt रखने जैसा है। बीते दौर के अवशेष बने हुए हैं, और ऐसा लगता है जैसे एक और अवशेष बनाया जा रहा हो
      हमारे product में भी हम इसे अनिच्छा से support करते हैं, लेकिन केवल तब जब संबंधित environment variable explicitly set हो। set न होने पर सभी Linux systems में default ऐसा होना चाहिए—XDG के इस behavior को हम 100% ignore करते हैं। क्योंकि यह MacOS जैसे दूसरे UNIX-जैसे systems की expected behavior से अलग है। हमने बस इतना डाला है कि Arch Linux के उत्साही लोग हर हफ्ते bug tracker पर आकर adoption की माँग न करें, और वे कुल users के 1% भी नहीं हैं। users को documentation में यह बताना ही काफी मुश्किल है कि वे अपने system पर हमारे product की files कहाँ ढूँढें। users हमेशा XDG जानते हों ऐसा भी नहीं, और ज़्यादातर लोगों के लिए XDG पहले से expected established convention भी नहीं है। साफ़ user directory चाहने वालों के अलावा इसमें कोई strong value नहीं है, और सबको इस specification पर ले जाने के लिए legacy बहुत ज़्यादा है
      सच कहूँ तो सब कुछ फिर से सोचकर desktop apps के लिए container-based solution की ओर जाना चाहिए, जहाँ वे छोटी जेल से बाहर न निकल सकें। लगभग snap apps जैसा। Nix से भी थोड़ा सीखा जा सकता है। हमें मान लेना चाहिए कि दुनिया भर के सभी Linux user apps से XDG बेस डायरेक्टरीज़, यहाँ तक कि user directories तक की चिंता करवाना और अपनवाना असफल रहा है। Mac और Windows ports support करना ही काफी कठिन है, और वे इस behavior का पालन नहीं करते। user permissions के साथ program चलाने वाले UNIX permission model से हटकर हर program को अपने खुद के uid से चलाना चाहिए। Android ऐसे ही काम करता है
    • सही, मैं भी उसी का इंतज़ार कर रहा हूँ

  • काश वह bug ठीक हो जाए जिसमें copy करने के लिए text होने के बावजूद copy option randomly disabled हो जाता है। सच में पागल कर देने वाला है

    • अच्छा है कि यह सिर्फ़ मेरे साथ नहीं हो रहा
    • देखते हैं 25 साल के अंदर ठीक होता है या नहीं। आजकल के तेज़ web environment के हिसाब से Mozilla कभी-कभी बहुत धीमा लगता है

  • AWS पुराने bugs और उनके सभी mentions को समय-समय पर मिटाकर यह समस्या हल करता है

    • यह bugs से बचने की ostrich strategy है

  • पिछले अगस्त की संबंधित पोस्ट:
    Happy 25th Birthday to Bugzilla
    https://news.ycombinator.com/item?id=37279543

  • बढ़िया! हालांकि 2000-03-28 अभी 25 साल पहले नहीं हुआ है

    • सुनने पर वाकई यह rounding का अजीब तरीका लगता है
    • सही। सच कहूँ तो मैं होता तो कुछ महीने और इंतज़ार करके silver wedding anniversary पर ठीक करता :P