บั๊ก Firefox <textarea> ที่ได้รับการแก้ไขหลังผ่านไป 25 ปี

 (bugzilla.mozilla.org)
1 คะแนน โดย GN⁺ 2024-05-23 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Bug 33654 อันเก่าแก่ของ Firefox คือปัญหาที่เมื่อ <textarea> ใช้ ROWS= และ COLS= จะบวกพื้นที่ของ scrollbar เข้าไปด้วย ทำให้ดูใหญ่กว่าจำนวนแถว·คอลัมน์ที่กำหนดไว้ และตอนนี้ถูกปิดในฐานะ รายการซ้ำของ Bug 1830576
  • ในสภาพแวดล้อมที่ปิด overlay scrollbars หรือใช้การตั้งค่า “always show scrollbars” จะเกิดซ้ำ ๆ ว่า <textarea rows=N> ถูกคำนวณให้สูงประมาณ N+1 แถว
  • การอภิปรายช่วงแรกขยายไปถึงการสืบทอดฟอนต์, การบังคับใช้ monospace, การคำนวณ cols จากความกว้างเฉลี่ยของ w และ W, รวมถึงวิธีจองพื้นที่สำหรับ scrollbar และมี testcase·patch·screenshot สะสมเป็นเวลานาน
  • ในทางปฏิบัติ rows=1 ดูเหมือนมี 3 แถว หรือ rows=2 ดูสูงเท่ากับ 3 แถว และที่ cols=80 ตำแหน่งตัดบรรทัดของ IE กับ Firefox ต่างกัน ทำให้ การควบคุมเลย์เอาต์ของฟอร์ม คลาดเคลื่อนกันตามแต่ละเบราว์เซอร์
  • เมื่อ Bug 1830576 กลายเป็น VERIFIED FIXED แล้ว การใช้ระยะเว้นของ scrollbar ใน WebKit, Chromium และ Firefox จึงสอดคล้องกัน และ Bug 33654 ถูกสรุปเป็น RESOLVED DUPLICATE

สถานะและขอบเขตของ Bug 33654

  • Bug 33654 คือข้อบกพร่องที่ <textarea> ใช้ ROWS= และ COLS= ผิด ทำให้เกิด พื้นที่เพิ่มเติมสำหรับ scrollbar ทั้งแนวนอน·แนวตั้งในสถานะที่ overlay scrollbars ถูกปิดอยู่
  • ผลิตภัณฑ์และคอมโพเนนต์คือ Core :: Layout: Form Controls ครอบคลุมเลย์เอาต์และรูปลักษณ์ของ HTML form controls โดยเฉพาะองค์ประกอบอย่าง textarea
  • สถานะปัจจุบันคือ RESOLVED DUPLICATE of bug 1830576
    • ชื่อของ Bug 1830576 ซึ่งเป็นรายการที่ซ้ำกันคือ Firefox sizes <textarea rows=N> as roughly N+1 rows tall, under an "always show scrollbars" configuration
    • สถานะของ Bug 1830576 คือ VERIFIED FIXED
  • บั๊กนี้ถูกเปิดเมื่อ 26 ปีก่อน และถูกปิดเป็น RESOLVED DUPLICATE เมื่อ 2 ปีก่อน
  • ในเมทาดาทาแสดงเวอร์ชัน Trunk, แพลตฟอร์ม x86 / All, ประเภท defect, ลำดับความสำคัญ P3, ระดับความรุนแรง S3
  • คีย์เวิร์ดคือ testcase, Whiteboard คือ [html][behavior]relnote-devel, จำนวนโหวตแสดงเป็น 99
  • ไฟล์แนบแสดงเป็น 17 files, 17 obsolete files โดยมี testcase·patch·screenshot ถูกอัปโหลดซ้ำ ๆ

อาการที่ปรากฏครั้งแรก

  • ในรายงานแรก Andrew McMillan ระบุว่าตัวอย่าง TEXTAREA ที่กำหนดเป็น ROWS=5 COLS=30 แสดงผลเหมือนประมาณ ROWS=7 COLS=48
  • ในคอมเมนต์ช่วงต้น มีกรณีต่อเนื่องว่า INPUT TYPE=TEXT และ TEXTAREA ไม่ได้ใช้ฟอนต์ที่กำหนดไว้อย่างถูกต้อง หรือแม้ scrollbar ปรากฏ พื้นที่ก็ยังสูงเกินไป
  • จากนั้นการอภิปรายเริ่มโน้มไปทางว่า textarea layout ได้รับข้อมูลผิด โดยคอลัมน์มี พื้นที่เพิ่มเติม และแถวมากเกินไปหนึ่งแถว
  • ความเป็นไปได้ว่าวิธีจองพื้นที่ล่วงหน้าสำหรับ scrollbar เป็นสาเหตุก็ถูกพูดถึงตั้งแต่ช่วงแรก

การคำนวณฟอนต์และแพตช์ช่วงแรก

  • ในกรณีจาก HTML authoring newsgroup เมื่อใช้ textarea { font-size: 8pt } ร่วมกับ <textarea cols="40" rows="12"> IE เรนเดอร์ความกว้างได้ถูกต้อง แต่ Mozilla ดูเหมือนคำนวณความกว้างโดยอิงฟอนต์ 12pt
  • ไฟล์ทดสอบที่ใช้ฟอนต์ arial มี <textarea NAME=system_code wrap=soft rows=5 cols=30 WRAP style="font-family:arial">
  • Rod มองว่าเมื่อใช้ฟอนต์พื้นฐาน การคำนวณขนาดถูกต้อง ดังนั้นประเด็นหลักไม่ใช่ sizing เอง แต่เป็น textarea ไม่ได้ใช้ ฟอนต์ที่ถูกต้อง
  • Kin พบโค้ดที่เมื่อมีการตั้งค่าแฟล็ก PlainText ของ editor จะบังคับใช้ font-family: monospace; กับพื้นที่เนื้อหาของ TextControl
    • เมื่อลบโค้ดนี้ออก ฟอนต์ที่ถูกต้องจะถูกใช้
    • แต่ในโหมด NavQuirks ยังมีปัญหาว่าสตริง 30 ตัวอักษรใน textarea 30 คอลัมน์กินความกว้างเพียงประมาณ 2/3 เท่านั้น
    • สาเหตุถูกชี้ไปที่วิธีที่ nsFormControlHelper หาความกว้างเฉลี่ยของ w และ W จากฟอนต์ แล้วคูณกับจำนวนคอลัมน์และบวกความกว้างของ scrollbar เพื่อคำนวณความกว้างของ textarea
  • Patch to use the correct font. เพิ่ม eEditorEnableWrapHackMask ให้กับแฟล็กเริ่มต้นของ plain text editor และจำกัดการใช้ font-family: monospace; แบบมีเงื่อนไข
  • แพตช์นี้เคยถูกดำเนินการเป็น RESOLVED FIXED แต่ถูกเปิดใหม่หลังผู้รายงานเดิมแจ้งว่าแม้ COLS=... จะถูกต้องแล้ว แต่ ROWS=... ยังทำงานผิดอยู่

การทำซ้ำและบั๊กที่ซ้ำกัน

  • รายการบั๊กที่ซ้ำกันมีปัญหาจำนวนมากที่ <textarea> ดูใหญ่กว่าจำนวนแถวที่กำหนดไว้หนึ่งบรรทัด หรือ rows=1 ดูเหมือน 3 บรรทัด
    • 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 ที่สามารถเปลี่ยนค่า rows และ cols ด้วยปุ่มได้ และไม่ได้ใช้ font tag หรือ variable-width font
    • ผลลัพธ์การทำงานคือมีคอลัมน์มากกว่าค่าที่กำหนดเสมอ 3 columns และแถวมักมากกว่า 1 แถว
    • เมื่อขอ rows=1 จะแสดง 3 rows
  • ใน Linux และ Win2000 trunk builds ปี 2002 มีกรณีว่า <textarea cols=40 rows=2></textarea> แสดงเป็น 3 rows และถ้าเป็น rows=N จะแสดงตรง ๆ เป็น N+1 rows
  • การทดสอบ W3C HTML 4.01 ก็ถูกใช้เป็นข้อมูลอ้างอิง และมีคอมเมนต์ว่าปัญหาเห็นได้ชัดในเทสต์ที่เกี่ยวกับ ROWS
  • แม้บน Windows 2000 และ Mozilla 0.9.3 ก็มีตัวอย่างถูกโพสต์ว่า textarea ที่ rows=1 เห็นได้ชัดว่าไม่ได้ดูเป็น 1 row

การอภิปรายเรื่องการคำนวณพื้นที่ scrollbar

  • Comment 86 อธิบายว่าขนาดของ textarea ถูกคำนวณเป็นค่า cols/rows ที่กำหนดไว้ บวกพื้นที่ scrollbar
  • มีการวิเคราะห์ว่า ต่างจาก IE ตรงที่ Mozilla แสดง scrollbar เฉพาะเมื่อจำเป็น ผู้ใช้จึงรู้สึกว่านี่เป็นพฤติกรรมที่เสีย
  • มีการเสนอทางเลือกที่เป็นไปได้สามแบบ
    • ไม่บวกขนาด scrollbar เมื่อคำนวณขนาด textarea
    • แสดง scrollbar เสมอเหมือน IE
    • รวมเฉพาะ scrollbar ที่จะแสดง
  • ทางเลือกที่สามถูกชี้ว่ามีลักษณะวนลูป เพราะขนาดขึ้นอยู่กับว่าจะมีการแสดง scrollbar หรือไม่ และการจะแสดง scrollbar หรือไม่ก็ขึ้นอยู่กับขนาดอีกที
  • Comment 87 เสนอทางเลือกที่สี่ว่า ROWS และ COLS ควบคุมเฉพาะขนาดเนื้อหาของ textarea และถ้ามี scrollbar ปรากฏ textarea ก็ขยายใหญ่ขึ้น
  • หลังจากนั้น ทิศทางการใช้งานถูกอภิปรายเป็นการ reflow ด้วย width/height ที่ไม่มี scrollbar เพื่อพิจารณาว่าจำเป็นต้องมี scrollbar หรือไม่ แล้วถ้าจำเป็นก็ค่อย reflow อีกครั้งด้วย width/height ใหม่

ผลกระทบที่ผู้ใช้เห็น

  • เมื่อกำหนด rows="2" แต่มี textarea สูง 3-row ปรากฏขึ้น เจตนาที่จะชี้นำปริมาณอินพุตด้วยภาพจะจางลง
    • เว็บแอปหนึ่งขอข้อความสรุปสั้น ๆ และใช้ rows="2" เพื่อชี้นำปริมาณอินพุตว่า “มากกว่าหนึ่งบรรทัด แต่ไม่ใช่เรียงความ”
    • ความแตกต่างของพฤติกรรมระหว่าง Firefox กับ IE6, Opera 8 ทำให้ค่า rows เดียวกันสร้างคำแนะนำทางภาพที่ต่างกันในแต่ละ user agent
  • แม้ในกรณีที่เนื้อหา textarea ไม่ได้ถูกเลื่อน ก็ยังมีคอมเมนต์ต่อเนื่องว่าพฤติกรรมของ Firefox ผิด
    • หากกำหนด rows="3" ให้ textarea ที่ส่วนใหญ่จะไม่เกินสามบรรทัด เช่น การป้อนที่อยู่ Firefox ก็ยังแสดง extra row เสมอ
    • หน้าจอใหญ่ขึ้นโดยไม่จำเป็น และผู้ใช้อาจคิดว่ากล่องใหญ่กว่าที่คาดจึงยังกรอกข้อมูลไม่พอ
  • ในการเปรียบเทียบ cols=80 มีคำอธิบาย screenshot ว่า IE เติม 1 จำนวน 80 ตัวจนถึงขอบ scrollbar แล้วจึงตัดบรรทัด แต่ Firefox ยังมีพื้นที่ให้ใส่ 1 เพิ่มอีก 2 ตัวหลัง 1 จำนวน 80 ตัว ก่อนที่ horizontal scrollbar จะปรากฏ
  • ในปี 2019 ยังมีคอมเมนต์ว่าปัญหายังคงอยู่ และการ์ด Trello ของ Discord เรื่อง Chat bar is a line taller than usual on Firefox ถูกนำเสนอเป็นกรณีผลกระทบ

ความพยายามทำแพตช์ที่ยืดเยื้อนาน

  • Hideo Saito แนบแพตช์และ testcase หลายครั้ง
    • patch for rows and cols
    • testcase แพตช์ wrap="off"
    • base patch
    • additional patch for another bug
    • patch which does not remove space
  • แนวทางหนึ่งคือให้ nsTextControlFrame::Reflow ทำงานด้วย intrinsic size ที่ไม่รวม scrollbar ก่อน แล้วหากมี scrollbar ให้บวกขนาด scrollbar เข้าไปใน intrinsic size และ reflow อีกครั้ง
  • ยังมีแนวทางแก้ GetScrollbarStyles เพื่อให้ text control frame ควบคุมว่าจะตั้ง scrollbar เป็น auto, hidden, scroll อย่างไร
  • roc ชอบแนวทางจัดการใน nsTextControlFrame มากกว่าวิธีใส่การเปลี่ยนแปลงจำนวนมากใน nsGfxScrollFrame
  • แพตช์หลังจากนั้นวนเวียนผ่านการรีวิวและแก้ใหม่รอบแล้วรอบเล่าเกี่ยวกับกลไกอย่าง SetScrollbarStyles, GetScrollbarStyles, SetScrollbarSpace, GetScrollbarOverflowState, FrameNeedsReflow, post-reflow callback
  • แพตช์บางส่วนได้รับ review- หรือถูกทำเครื่องหมาย obsolete และผู้รีวิวชี้ว่าจำเป็นต้องอัปเดตให้ตรงกับ trunk

วิธีเลี่ยงชั่วคราวและข้อจำกัด

  • มีข้อเสนอว่าหากเพิ่ม CSS textarea{ overflow-x: hidden } ปัญหาจะได้รับการแก้ไข
  • วิธีนี้มีเงื่อนไขว่าใช้ได้เฉพาะกรณีที่ไม่ต้องการ horizontal scrollbar
  • คอมเมนต์อื่นแย้งว่าบั๊กนี้แก้ไม่ได้ด้วย CSS overflow เพียงอย่างเดียว และ Firefox เป็นเบราว์เซอร์เดียวที่เรนเดอร์ textarea โดยเพิ่มอีกหนึ่งบรรทัด
  • Emilio Cobos Álvarez กล่าวว่า สาเหตุดูเหมือนมาจากขนาด scrollbar และเมื่อใช้ scrollbar-width: none กับ <textarea> ดูเหมือนจะแก้ได้
  • คอมเมนต์เดียวกันเสริมว่า ถึงอย่างนั้นตัวบั๊กเองก็ควรถูกแก้ไขอยู่ดี

สรุปขั้นสุดท้าย

  • เมื่อ 3 ปีก่อน BugBot ระบุว่าบั๊กนี้มี severity ค่อนข้างต่ำที่ S3 แต่มีรายการซ้ำ 27 รายการ, โหวต 103 รายการ, CC 91 รายการ จึงขอให้พิจารณายกระดับ severity
  • สรุปบั๊กถูกเปลี่ยนจาก 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
  • Luke Warlow ถามว่าเมื่อ Bug 1830576 ถูกแก้แล้ว การใช้ระยะเว้นของ scrollbar ของ WebKit, Chromium และ Firefox ก็สอดคล้องกัน จึงสามารถปิดบั๊กนี้ได้หรือไม่
  • Emilio Cobos Álvarez เห็นด้วย และ Bug 33654 ถูกเปลี่ยนจาก NEW เป็น RESOLVED พร้อมปิดเป็น DUPLICATE
  • รายการที่ซ้ำกันถูกกำหนดเป็น Bug 1830576 และบั๊กดังกล่าวมีสถานะ VERIFIED FIXED

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-05-23
ความเห็นจาก Hacker News

  • ฮ่า! ฉันติดตามบั๊กนี้มาเกือบ 25 ปีเต็ม เลยทีเดียว ตอนนั้นยังไม่มี Firefox และมันถูกลงทะเบียนเป็นบั๊กฝั่ง Mozilla ในช่วงก่อนหรือหลัง Netscape Navigator ไม่ใช่ของ Netscape Navigator เอง
    จำไม่ได้แล้วว่าทำไมถึงติดตามไว้ แต่คงน่าจะเคยคอมเมนต์ไว้ มีอีเมลแจ้งเตือนส่งมาทุก ๆ สองสามปีเลยขำทุกครั้ง และในที่สุดเมื่อไม่กี่วันก่อนมันก็ถูกแก้แล้ว

    • น่าทึ่งที่สถานะการติดตามเธรดบั๊กนั้นยังอยู่รอดมาได้ตลอดเวลายาวนานขนาดนั้น
    • ฉันก็คล้ายกัน จำได้ว่าตอนเริ่มคิดครั้งแรกว่าจะลองทำเว็บเป็นอาชีพดีไหม ฉันเคยหลงใหลกับจินตนาการเรื่องเว็บไซต์ที่พื้นหลัง โปร่งใสหรือกึ่งโปร่งใส จนมองทะลุไปถึงเดสก์ท็อปได้
      ฉันคิดมาตลอดว่าอะไรอย่าง html { background: transparent; } ก็น่าจะทำงานได้เลย แต่การแก้บั๊กครั้งนี้ไม่ได้ทำแบบนั้นจริง ๆ อย่างแรก มันไม่ใช่ฟีเจอร์ที่เว็บไซต์เลือกใช้ได้เป็นค่าเริ่มต้น แต่เป็นการตั้งค่าที่ผู้ใช้หรือส่วนขยายเปิดได้แทน ซึ่งอาจดีกว่า เพราะถ้าอนุญาตเป็นค่าเริ่มต้นก็คงเปิดทางใหม่ให้ clickjacking
    • จะบอกว่ามัน “ถูกลงทะเบียนสำหรับ Netscape Navigator” ก็ไม่ค่อยถูกนัก มันเป็นฝั่ง Mozilla Suite มากกว่า ปี 2000 นี่ก็เข้าสู่ยุค Mozilla ไปพอสมควรแล้ว และบั๊กของ Netscape ก็ดูไม่น่าจะเข้า Bugzilla ด้วย
    • ว้าว บั๊กนี้เก่ากว่า Firefox เองอีก
    • ลำดับต่อไปคงถึงเวลาที่ เวอร์ชันทิกเก็ต ข้ามโปรเจกต์ใน Jira จะได้รับการแก้ไข

  • แม้จะนอกประเด็นนิดหน่อย แต่ฉันเกลียดกระแสการแสดง ช่วงเวลาแบบอ่านง่ายสำหรับมนุษย์ อย่าง “หนึ่งเดือนก่อน” มาก แสดงวันที่มาเลย ฉันคำนวณเองได้
    Outlook อย่างน้อยในเวอร์ชัน Mac นี่แย่สุด อีเมลก่อนวันนี้จะแสดงแค่เช่น “เมื่อวาน” และต้องคลิกเมลถึงจะเห็นเวลา พอได้รับอีเมลวันละหลายสิบฉบับ แล้วมีข้อความ 50 อันเรียงกันเป็น “เมื่อวาน” หมด มันไม่มีประโยชน์อะไรเลย

    • น่าจะดีถ้าเอาเมาส์ไปชี้บนข้อความแบบอ่านง่ายแล้วมี timestamp ที่แน่นอน โผล่มา
    • อยากให้กระแสนี้หายไปเร็ว ๆ จริง ๆ เมลมาถึงตอน 6 โมงเช้าหรือ 5 ทุ่มของวันนั้นต่างกันมาก แค่บอกว่า “เมื่อวาน” มันไม่พอ
      เบียร์ควรเย็น และ timestamp ก็ควรแม่นยำ
    • ถ้ามันยังผิดอีกก็ยิ่งแย่ Discogs บอกว่าเดือนตุลาคม 2021 คือ “มากกว่า 3 ปีที่แล้ว”
    • ประโยคที่ว่า “แสดงวันที่มาเลย ฉันคำนวณเองได้” สำหรับฉันนี่กลับยากมาก ฉันมีปัญหาค่อนข้างมากกับแนวคิดเรื่องวันที่หรือ การไหลผ่านของเวลา เอง
    • ถ้าเอาเมาส์ไปชี้บนวันที่ก็จะเห็นวันที่และเวลาที่แน่นอน

  • Bugzilla ของ Firefox น่าจะเป็นหนึ่งใน ตัวติดตามบั๊ก ที่เปิดใช้งานมายาวนานที่สุดอย่างแน่นอน น่าประทับใจที่ผ่านการปรับปรุงมามากมายแต่ยังคงกลิ่นอายดั้งเดิมไว้ได้มาก แต่ก่อนมันเคยเป็นโค้ดเบสที่ค่อนข้างหยาบและเหมือนสัตว์ประหลาด
    ราวปี 2000 ตอนนั้นในองค์กรพัฒนา Windows มีการตั้งอินสแตนซ์ขึ้นมาเพื่อแทนที่ตัวติดตามบั๊กภายในที่สร้างบน Microsoft Access/Outlook มันซับซ้อน แต่ช่วงหนึ่งก็เกือบจะเป็นตัวติดตามบั๊กที่ดีที่สุดแล้ว FogBugz เองก็เพิ่งเริ่มในช่วงนั้น และฉันมองว่าทีมนั้นเป็นหนึ่งในทีมแรก ๆ ที่ให้ความสำคัญกับประสบการณ์ผู้ใช้อย่างจริงจัง

    • ทุกวันนี้ก็ยังเอาชนะ Bugzilla ได้ไม่ง่าย จริง ๆ แล้วตัวเลือกสมัยนี้บางตัวแย่กว่า Bugzilla มากจนไม่เข้าใจว่ามีอยู่ได้อย่างไร เช่น Mantis BT ที่ Dwarf Fortress ใช้อยู่นี่แย่มาก
      ในทางกลับกัน FogBugz เป็นเครื่องมือที่ฉันอยากลองใช้สักครั้งเสมอถ้ามีโอกาส

  • เห็นอะไรแบบนี้แล้วอบอุ่นใจ ช่วงหลังฉันก็เพิ่งเจอเรื่องคล้ายกันกับบั๊ก Firefox อายุ 24 ปี: https://bugzilla.mozilla.org/show_bug.cgi?id=62151

    • ให้ตายสิ ยังจำได้เลยว่าฉันเคยติดอยู่กับปัญหานี้จนงมหาอยู่พักใหญ่

  • สำหรับบั๊กที่ค้างมานาน สิ่งที่น่าหงุดหงิดที่สุดคือ LibreOffice ยังตั้งค่าแกน x ของ scatter plot ให้เป็น รูปแบบวันที่ อย่างถูกต้องไม่ได้
    https://bugs.documentfoundation.org/show_bug.cgi?id=54132
    เป็นบั๊กอายุ 12 ปีแล้ว จากคอมเมนต์ดูเหมือนทุกคนลังเลจะแก้ เพราะโค้ด “ซับซ้อนจนน่ากลัว” และมีโอกาสสูงที่จะทำให้เกิด regression

    • ฉันหวังให้ LibreOffice เอาฟีเจอร์จาก Excel ที่ฉันชอบมาใช้บ้าง แต่พอเห็นแบบนี้แล้วความคาดหวังก็น้อยลง
    • ถ้าต้องการแค่สเปรดชีตกับแพ็กเกจทำกราฟ บน Linux gnumeric ก็เป็นตัวเลือกที่ดี
    • ช่วงเวลาที่ดีจริง ๆ คือเมื่อผู้ดูแลเริ่มกลัวโค้ดที่พวกเขาเองอนุญาตให้ merge

  • หวังว่าคราวหน้าจะจัดการเรื่อง XDG ด้วย อันนี้ก็รอมา 20 ปีแล้วเหมือนกัน [1]
    [1] https://bugzilla.mozilla.org/show_bug.cgi?id=259356

    • ดูแล้วคงไม่มีวันไหนที่ XDG Base Directory จะถูกยอมรับใช้อย่างสมบูรณ์และแพร่หลายจริง ๆ ตอนนี้ก็ผ่านมา 21 ปีแล้ว ถ้า Arch Linux ไม่ได้กดดันโปรแกรมที่ไม่ทำตามมันอย่างหนัก เช่น ล็อกสิทธิ์ไดเรกทอรีโฮมของผู้ใช้ root มันก็คงไม่โตมาถึงขนาดนี้ในช่วงหลัง
      พูดตามตรง สเปกนี้ไม่ได้แก้ปัญหาจริงที่ผู้ใช้เจออย่างจริงจังนัก การยอมรับส่วนใหญ่เกิดจากคนที่รำคาญโครงสร้างไดเรกทอรี $HOME ไปกดดันผู้ดูแลแพ็กเกจอย่างต่อเนื่อง และผู้ใช้ 99% ก็ไม่สนว่าโปรแกรมจะทำตาม XDG Base Directory หรือไม่ มันแค่ทำให้พูดได้ว่า “ดูสะอาดกว่า” ตามสเปกของ freedesktop ที่ตลอด 20 กว่าปีก็ยังไม่ได้รับการยอมรับอย่างกว้างขวาง
      ส่วนตัวผมไม่ชอบการแยก config/data/cache แบบหลวม ๆ และเจตนาที่เป็นนัยของมัน ไม่ใช่ทุกอย่างที่จะเข้ากับหมวดพวกนั้นได้ และพอเป็นแบบนั้นก็ยิ่งทำให้คาดเดาพฤติกรรมของระบบได้ยาก เดมอนจะลบแคชของผมหรือเปล่า? ผู้ใช้จะคัดลอกโฟลเดอร์ config ไปมาหรือเปล่า? อะไรกันแน่ที่ควรสำรองข้อมูล? ในสเปกไม่มีมาตรฐานว่าควรปฏิบัติกับโฟลเดอร์เหล่านี้จริง ๆ อย่างไร มันคลุมเครือโดยตั้งใจ แต่เป็นความคลุมเครือที่พอคนตั้งสมมติฐานแล้วอาจพังได้
      มันคล้ายกับการแยก /usr ออกจาก root หรือแยก /usr/local ออกจาก root หรือมี /opt อยู่ด้วย ให้ความรู้สึกเหมือนเป็นความตกค้างจากยุคก่อนที่ยังหลงเหลืออยู่ แล้วกำลังจะสร้างอันใหม่เพิ่มอีก
      ในผลิตภัณฑ์ของเราก็รองรับแบบเสียไม่ได้เหมือนกัน แต่รองรับเฉพาะเมื่อมีการตั้ง environment variable นั้นไว้อย่างชัดเจนเท่านั้น เราเพิกเฉยต่อพฤติกรรมของ XDG ที่บอกว่าเมื่อไม่ได้ตั้งค่าไว้ ค่าเริ่มต้นบนทุกระบบ Linux ควรเป็นแบบนี้ 100% เพราะมันไม่เหมือนวิธีที่ระบบตระกูล UNIX อื่น ๆ อย่าง MacOS คาดหวังไว้ เราใส่มาแค่พอไม่ให้แฟนพันธุ์แท้ Arch Linux แห่มาถล่ม bug tracker ทุกสัปดาห์เพื่อเรียกร้องให้รองรับ ซึ่งคนกลุ่มนั้นมีไม่ถึง 1% ของผู้ใช้ทั้งหมด แค่ทำเอกสารบอกผู้ใช้ว่าควรหาไฟล์ของผลิตภัณฑ์เราในระบบตัวเองจากที่ไหนก็ยากพออยู่แล้ว ผู้ใช้ก็ไม่ได้รู้จัก XDG กันเสมอไป และสำหรับคนส่วนใหญ่ XDG ก็ยังไม่ใช่ธรรมเนียมที่ตั้งมั่นจนคาดหวังได้อยู่แล้ว นอกจากคนที่อยากให้ไดเรกทอรีผู้ใช้ดูสะอาด ก็แทบไม่มีคุณค่าเด่นชัดพอ แต่ระบบเดิมมีภาระตกทอดมากเกินไปกว่าจะย้ายทุกอย่างไปตามสเปกนี้ได้
      พูดตามตรงควรคิดกันใหม่ทั้งหมดแล้วไปทาง แนวทางแบบคอนเทนเนอร์ ที่ทำให้แอปเดสก์ท็อปออกจากคุกเล็ก ๆ ของตัวเองไม่ได้ คล้ายกับแอป snap มาก ๆ อาจเรียนรู้อะไรจาก Nix ได้บ้าง ควรยอมรับว่าแนวคิดจะทำให้แอปผู้ใช้บน Linux ทั่วโลกทั้งหมดสนใจและยอมรับ XDG Base Directory หรือกระทั่ง user directory นั้นล้มเหลวแล้ว แค่ต้องรองรับพอร์ตบน Mac และ Windows ก็ยากพอแล้ว ซึ่งระบบพวกนั้นก็ไม่ได้ทำงานแบบนี้ ควรเลิกโมเดลสิทธิ์แบบ UNIX ที่รันโปรแกรมด้วยสิทธิ์ของผู้ใช้ แล้วให้แต่ละโปรแกรมรันด้วย uid ของตัวเองแทน Android ก็ทำงานแบบนั้น
    • ใช่เลย ผมก็หวังอย่างนั้นเหมือนกัน

  • อยากให้ช่วยแก้บั๊กที่ ตัวเลือกคัดลอก ถูกปิดใช้งานแบบสุ่มทั้งที่มีข้อความให้คัดลอกทีเถอะ มันชวนเสียสติจริง ๆ

    • โล่งใจที่ไม่ใช่มีแค่ผมที่เจอ
    • ต้องมาดูกันว่าจะซ่อมได้ภายใน 25 ปีไหม Mozilla บางทีก็ช้าเกินไปสำหรับโลกเว็บที่เร็วขนาดนี้ในทุกวันนี้

  • AWS แก้ปัญหานี้ด้วยการลบบั๊กเก่า ๆ และลบทุกการพูดถึงมันเป็นระยะ

    • เป็น กลยุทธ์นกกระจอกเทศ ในการหลบปัญหา

  • โพสต์ที่เกี่ยวข้องเมื่อเดือนสิงหาคมที่ผ่านมา:
    Happy 25th Birthday to Bugzilla
    https://news.ycombinator.com/item?id=37279543

  • เจ๋งดี! แค่ 2000-03-28 ยังไม่ใช่ 25 ปีก่อน

    • ฟังดูแล้วเป็นวิธีปัดตัวเลขที่แปลกใช้ได้เลย
    • ใช่เลย เอาจริงถ้าเป็นผมคงรออีกสักสองสามเดือนแล้วค่อยแก้ให้ตรงกับ วันครบรอบแต่งงานเงิน มากกว่า :P