บั๊ก Tooltip ของ Firefox ที่ได้รับการแก้ไขหลังผ่านไป 22 ปี

 (bugzilla.mozilla.org)
1 คะแนน โดย GN⁺ 2023-10-11 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • บั๊ก tooltip-ghost ซึ่งทำให้ tooltip ยังคงค้างอยู่ด้านหน้าแม้ Firefox จะอยู่เบื้องหลัง ถูกติดตามใน Bugzilla มาเป็นเวลานาน และมีสถานะเป็น VERIFIED FIXED ใน Firefox 119 Branch
  • วิธีทำซ้ำครั้งแรกคือเลื่อนเมาส์ไปวางบนลิงก์หรือไอคอนบน toolbar เพื่อ แสดง tooltip แล้วสลับไปแอปอื่นด้วย Command-Tab หรือ Alt-Tab จากนั้น tooltip ไม่หายไป
  • มีกรณีคล้ายกันเกิดขึ้นต่อเนื่อง ไม่ใช่แค่บน Mac OS X, Windows และ Linux แต่รวมถึง Thunderbird, Sunbird และ Lightning ด้วย และใน Firefox 5.0.1 เพียงแค่เมาส์เคลื่อนผ่านเหนือหน้าต่างเบื้องหลังก็ทำให้เกิด tooltip และ สถานะ mouseover ได้
  • แพตช์สุดท้ายคือ only show tooltip when document has focus โดยเปลี่ยนให้แสดง tooltip เฉพาะเมื่อเอกสาร มี focus เท่านั้น และถูกนำเข้า mozilla-central ด้วย revision 8ae372dc88d1
  • QA ทำซ้ำได้ตามขั้นตอนเดิมบน Firefox 106.0.1 กับ Ubuntu 22.04 จากนั้นยืนยันว่าใน build Nightly 120.0a1 ปัญหาไม่เกิดขึ้นต่อ และภายหลังมีการเชื่อมโยงบั๊ก regression ที่เกี่ยวข้องบางรายการแยกต่างหาก

Tooltip ที่ค้างอยู่เหนือ Firefox เบื้องหลัง

  • Bug 148624 กล่าวถึง ปัญหาที่ tooltip ยังคงค้างอยู่ด้านหน้า แม้ Firefox จะอยู่เบื้องหลัง
  • ชื่อเดิมคือ Tooltips persist in foreground when Firefox is in background และมี alias ว่า tooltip-ghost
  • สถานะคือ VERIFIED FIXED และ target milestone คือ 119 Branch
  • การจัดหมวดหมู่คือ Core :: XUL, type คือ defect และ severity คือ S3

ขั้นตอนทำซ้ำครั้งแรกและพฤติกรรมที่คาดหวัง

  • สภาพแวดล้อมในรายงานแรกคือ Mozilla/5.0 ... Mac OS X ... Gecko/20020602 BuildID: 2002060203
  • ขั้นตอนทำซ้ำนั้นเรียบง่าย
    • เลื่อนเมาส์ไปวางบนไอคอน toolbar หรือลิงก์
    • รอจน tooltip ปรากฏ
    • ส่ง Mozilla ไปอยู่เบื้องหลังด้วย Command-Tab
  • สิ่งที่เกิดขึ้นจริงคือ กล่อง tooltip สีเหลืองขนาดเล็ก ยังคงค้างอยู่ด้านหน้าต่อไป
  • พฤติกรรมที่คาดหวังคือ tooltip ควรหายไปเมื่อ Mozilla ถูกสลับไปอยู่เบื้องหลัง
  • ผู้รายงานเดิมระบุว่า tooltip จะหายไปก็ต่อเมื่อนำ Firefox กลับมาด้านหน้าแล้วเลื่อนเมาส์ออกจาก toolbar

กรณีทำซ้ำที่เกิดขึ้นต่อเนื่องบนหลายแพลตฟอร์ม

  • หลังจากการยืนยันในช่วงแรก ขอบเขตแพลตฟอร์มถูกเปลี่ยนจาก Mac OS X เป็น All และปัญหาเดียวกันทำซ้ำได้บน Windows XP และ Windows 98 ด้วย
  • มีกรณีเกิดขึ้นต่อเนื่องบน 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 เป็นต้น
  • พบอาการคล้ายกันในสภาพแวดล้อม Thunderbird, Sunbird และ Lightning ด้วย
    • ใน Thunderbird 2.0.0.17 กับ Lightning 0.9 มีการแนบกรณีที่ tooltip ของหน้าต่างงานค้างอยู่เหนือหน้าต่างแจ้งเตือน
    • ทำซ้ำได้บน GNU/Linux ด้วยชุด Thunderbird 102.4.1 และ Firefox 106.0.1
    • มีการส่งขั้นตอนทำซ้ำในสภาพแวดล้อม Firefox 117.0 กับ Thunderbird 115.2.0 รวมถึง xfce และ xfwm
  • ผู้ใช้รายหนึ่งระบุว่ายังคงเกิดขึ้นบน Firefox 115.0.2 กับ GNOME 44 และใช้วิธีเลี่ยงโดย ปิดใช้งาน tooltip ทั้งหมด ผ่านการตั้งค่า browser.chrome.toolbar_tips

ผลกระทบที่มากกว่า tooltip ที่ค้างอยู่

  • ไม่ใช่แค่ tooltip ที่ปรากฏอยู่แล้วค้างอยู่เท่านั้น แต่ยังยืนยันอาการที่ tooltip ใหม่ปรากฏขึ้น เมื่อเมาส์เคลื่อนผ่านบริเวณที่เกี่ยวข้องของหน้าต่าง Firefox ระหว่างที่ Firefox อยู่เบื้องหลังด้วย
  • มีการแนบกรณีใน Firefox 5.0.1 ที่ Transmission อยู่ด้านหน้าและ Firefox อยู่เบื้องหลัง โดยเมื่อขยับเมาส์บนหน้าต่าง Transmission Inspector กลับไป trigger tooltip ของ Firefox
  • ยังมีกรณีที่ tooltip ขนาดใหญ่ของปุ่ม toolbar ของ Adblock Plus ปรากฏเหนือ Transmission
  • มีกรณีที่ tooltip Options ของ Transmission กับ tooltip ของช่องค้นหา Google ใน Firefox แสดงพร้อมกันและซ้อนทับกัน
  • ในรายการบน bookmark toolbar ไม่เพียงแต่ tooltip เท่านั้น แต่ สถานะ mouseover ก็ถูก trigger ด้วย
    • สถานะของปุ่ม bookmark เปลี่ยนก่อน แล้ว URL tooltip จึงปรากฏหลังจากนั้นไม่นาน
    • ปุ่ม + ของ Open a New Tab ก็ถูกบันทึกเป็นข้อยกเว้นที่เกิดสถานะ mouseover และ tooltip ได้แม้อยู่ในสถานะเบื้องหลัง

แนวทางแก้ไขและแพตช์ที่ถูกนำเข้า

  • ในการอภิปรายช่วงต้นทศวรรษ 2010 มีข้อเสนอให้ไม่แสดง tooltip หากหน้าต่างไม่มี focus ตอนที่ timer ของ tooltip ทำงาน
  • Safari และ Google Chrome ถูกใช้เป็นกรณีเปรียบเทียบว่าไม่แสดง tooltip บน Mac เมื่อไม่ได้เป็นแอปด้านหน้า
  • คำอธิบายแพตช์สุดท้ายคือ only show tooltip when document has focus
  • แพตช์ถูกอัปโหลดเป็น attachment บน Phabricator และต่อมาถูกนำเข้า autoland และ mozilla-central
  • สถานะเปลี่ยนจาก ASSIGNED เป็น RESOLVED และ resolution กลายเป็น FIXED

การตรวจสอบโดย QA และ regression ภายหลัง

  • QA ยืนยัน issue ได้ตามขั้นตอนทำซ้ำเดิมบน Firefox 106.0.1 และ Ubuntu 22.04
  • ในสภาพแวดล้อมเดียวกัน ปัญหาไม่เกิดขึ้นต่อใน Nightly 120.0a1 ล่าสุด จึงเปลี่ยนสถานะเป็น VERIFIED
  • สถานะ firefox119 เปลี่ยนจาก fixed เป็น verified
  • ผู้ใช้รายหนึ่งระบุว่าปัญหาปรากฏเฉพาะเมื่อ MOZ_ENV_XINPUT2=1 และหายไปเมื่อ MOZ_ENV_XINPUT2=0 ซึ่งเชื่อมโยงกับ bug 1809029
  • ต่อมามีการเชื่อมโยงบั๊กต่อไปนี้ในฐานะ regression ที่เกี่ยวข้อง
    • 1857513: tooltip ของ bookmark sidebar ไม่ปรากฏจากการ hover เมื่อ sidebar ไม่มี focus
    • 1861427: tooltip ไม่ปรากฏอีกต่อไปเมื่อ hover ในขณะที่แอปพลิเคชันอื่นมี focus
    • 2043757: บน Windows 11 ชื่อแท็บไม่ปรากฏจากการ hover เมื่อ Firefox ถูกหน้าต่างอื่นบังไว้บางส่วน

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

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

 
GN⁺ 2023-10-11
ความคิดเห็นบน Hacker News

  • หากสงสัยว่าใน codebase ของ Firefox เขาหาและแก้บั๊กกันอย่างไร Mike Conley ถ่ายทอดสดงานพัฒนาที่เขาทำที่ Mozilla ทุกสัปดาห์มาหลายปีแล้ว
    วิดีโอที่บันทึกไว้จำนวนมากเป็นกระบวนการเลือกบั๊กหนึ่งรายการจาก backlog แล้วไล่แกะอย่างละเอียดจนจับสาเหตุได้
    แนะนำเป็นพิเศษหากคุณเพิ่งเริ่มเขียนโปรแกรมและอยากเห็นว่าการทำงานกับ codebase จริงเป็นอย่างไร: https://youtube.com/@mikeconleytoronto

    • สมัยเรียนมหาวิทยาลัย ผมเคยเป็นอาสาสมัครกับ Mozilla อยู่มากพอสมควร ในช่วงเวลาที่น่าจะเก่าไล่เลี่ยกับตอนที่บั๊กนี้ถูกแจ้งเข้ามา
      ตอนแรกอยู่ทีม QA ทำหน้าที่ คัดแยกบั๊ก ตรวจว่า Bugzilla component ถูกต้องไหม ขั้นตอนการ reproduce สมเหตุสมผลหรือไม่ เป็นต้น
      แม้จะไม่มีประสบการณ์ทำงานจริงเลย แต่แค่ได้เห็นว่าโปรเจกต์ขนาดใหญ่ดำเนินงานอย่างไร นักพัฒนาจริงจัดการการแก้ไขและฟีเจอร์ต่าง ๆ อย่างไร ก็ได้เรียนรู้อย่างมากแล้ว และยังได้รู้จักแนวคิดอย่าง diff, patch, CI/CD ด้วย ตอนนั้นเป็น nightly build จึงพูดอย่างเคร่งครัดไม่ได้ว่าเป็น continuous integration แต่ทิศทางก็ใช่
      ต่อมาผมเรียนรู้วิธี build แอป ซึ่งโดยเฉพาะบน Windows นั้นลำบากมาก ผม build ทั้ง Firefox, Thunderbird และ Mozilla Suite ที่ตอนนั้นยังมีอยู่ ซึ่งเป็นชุดรวมเบราว์เซอร์ เมล HTML editor และอื่น ๆ
      สุดท้ายก็ได้ contribute การแก้บั๊กเองอยู่สองสามรายการ แม้จะเป็นแค่แก้ typo หรือไอคอนที่วางไม่ตรง แต่ความรู้สึกที่โค้ดซึ่งผู้ใช้จริงหลายล้านคนใช้อยู่ถูกปล่อยออกไปนั้นสุดยอดมาก
      หลังเรียนจบ ประสบการณ์นี้ช่วยได้ทันทีในงานแรก ผมเริ่มจาก IT support และ QA ที่สตาร์ทอัพแห่งหนึ่ง ซึ่งไม่มีระบบอัตโนมัติสำหรับ build และ deploy เลย ต่อให้ใคร push เข้า SVN ก็อาจไม่มีใครรู้ไปหลายวันว่า build พังหรือไม่
      จากสิ่งที่เรียนมาจาก Mozilla ผมใช้สักอย่างในบรรดา Buildbot, CruiseControl, Hudson สร้าง build server ที่ build เมื่อมีการ push และส่งอีเมลแจ้งทีมเมื่อ compile ล้มเหลวหรือ test fail
      ค่อนข้างสนุกดีที่นักพัฒนามากประสบการณ์ถามว่า “คน IT ของเรารู้เรื่องแบบนี้ได้ยังไงกัน” และผมสามารถสร้างบทบาทแบบนั้นขึ้นมาเองได้ตั้งแต่ก่อนจะมีคำว่า DevOps ทั้งหมดนี้เป็นเพราะได้เรียนรู้จากการลองแตะ Mozilla ในเวลาว่าง
      สรุปคือผมเห็นด้วยเต็มที่ว่าการลอง hack โปรเจกต์ Mozilla เป็นวิธีที่ดีในการได้ประสบการณ์ทำงานจริง

  • ในที่สุดก็แก้แล้วสินะ อยากให้ Mozilla ทำเรื่องแบบนี้ให้มากขึ้น
    หนึ่งในรูปแบบที่น่ารำคาญที่สุดของบั๊กนี้คือเวลาเปิดเกมแบบเต็มจอ เมาส์ถูก reposition แล้ว tooltip โผล่ขึ้นมา จากนั้นมันลอยทับอยู่บนเกม
    เกมไม่ชอบเสีย focus และถูก Alt-Tab เพื่อจัดการกับ Firefox สุดท้ายบางครั้งก็ต้อง restart เกม

    • พอดีตอนนี้กำลังฟังพรีเซนต์ที่ Jonathan Blow พูดใน DevGAMM เมื่อ 4 ปีก่อน ข้อบกพร่องทำนองนี้โผล่มาเป็น motif ซ้ำ ๆ
      https://www.youtube.com/watch?v=ZSRHeXYDLko&t=2729s
    • ผมยังรอให้ พฤติกรรมพื้นฐานของ container tabs ได้รับการแก้ไขอยู่เลย มันทำให้อดคิดไม่ได้ว่า product management พังไปหมดแล้วหรือเปล่า
      [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1479858
    • จำได้ว่าเมื่อหลายปีก่อนเคยคอมเมนต์ในบั๊กทำนองว่า “ผมก็เจอเหมือนกัน และมีข้อมูลแบบนี้”
      สุดท้ายผมเลิกใช้ Firefox โดยสิ้นเชิงราว 10 ปีก่อน เหตุผลหลักคือบั๊กนี้กวนใจวันละหลายครั้งติดต่อกันหลายปี และช่วงนั้น Chrome ก็ดีพอจะใช้แทนได้แล้ว
      ข้อความใน tooltip ก็มักเป็นคำทั่วไปอย่าง “Previous” ทำให้ต้องกลับไป focus หน้าต่าง Firefox แทบทุกหน้าต่างเพื่อหาว่ามันมาจากไหน และการตามหาจนกว่า tooltip นั้นจะหายไปเป็นเรื่องทรมานเสมอ แถมมันยังลอยอยู่เหนือทุกหน้าต่างด้วย

  • ที่น่าทึ่งยิ่งกว่าคือพฤติกรรมนี้ไม่เปลี่ยนไปโดยบังเอิญเลยตลอดหลายปีที่ผ่านมา เป็น bug backward compatibility ที่น่าประทับใจมาก

  • ผมเคยโทษ window manager บน Linux desktop หลายตัวมาตลอดว่าเป็นสาเหตุของบั๊กนี้ เพิ่งรู้ตอนนี้เองว่าผู้ร้ายเป็นตัวเดิมมาตลอด
    บนหน้าจอเล็ก ๆ บางครั้งมันค่อนข้างน่ารำคาญ เพราะอาจบังฟอร์มหรือองค์ประกอบสำคัญอื่น ๆ
    ตั้งตารออัปเดต และหวังว่าในอีก 22 ปีข้างหน้า Firefox จะไม่เพียงไร้บั๊ก แต่ยังกลับมาเป็นแอปพลิเคชันที่ทรงอิทธิพลเหมือนเมื่อก่อนด้วย

    • ถึงอย่างนั้นผมก็คงจะโทษ window manager ต่อไปอยู่ดี ผมแน่ใจว่าเคยเห็นมันนอก Firefox ด้วย และแม้แต่นอก Linux ด้วยซ้ำ
    • มันเกิดบน Windows ด้วย และยังเกิดซ้ำในแอปพลิเคชันอื่น ๆ ข้ามระบบปฏิบัติการไปมา จึงโทษ component หรือ GUI layer ตัวใดตัวหนึ่งโดยเฉพาะไม่ได้
    • เหมือนจะเคยเห็นใน LibreOffice ด้วย
    • ที่อื่นก็เกิดเหมือนกัน ผมเห็นบ่อยใน DBeaver
    • ผมก็เจอเป็นประจำใน Chrome บน Fedora/GNOME/X.Org

  • https://phabricator.services.mozilla.com/rMOZILLACENTRAL8ae3...
    ถ้าคุณเห็นแพตช์ห้าบรรทัดที่แก้บั๊กนี้แล้วคิดว่า “ฉันก็ทำได้นี่!” จริง ๆ แล้วคุณก็ทำได้
    คำถามจริง ๆ คือ “แล้วทำไมไม่ทำล่ะ?”
    ถ้าลองตอบตัวเอง ประเด็นสำคัญอยู่ที่ว่าการคอมไพล์ Firefox และรัน ชุดทดสอบ นั้นง่ายแค่ไหน
    กระบวนการไล่ตามบั๊กที่ยาวหลังจากนั้นต่างหากคือส่วนที่สนุก

    • ปกติผมมักมีส่วนร่วมกับซอฟต์แวร์ที่ใช้เป็นประจำ และเคยพยายามทำอะไรสักอย่างกับ Firefox ด้วย แต่สำหรับคนนอกมันยากเกินไป เลยยอมแพ้ไป
      ทั้ง hg, หลายรีโพสิทอรี, วิกิเก่า ๆ, บิลด์ที่ซับซ้อนมาก, Bugzilla ฯลฯ ระบบทั้งหมดพันกันจนเริ่มเข้าไปมีส่วนร่วมได้ยากมาก
      ถ้า Firefox อยู่บน GitHub หรืออย่างน้อยก็ GitLab ที่โฮสต์เอง แล้วแค่ fork มาลองแก้และรัน CI แบบเดียวกันได้ เรื่องคงต่างไปโดยสิ้นเชิง อยากให้มันง่ายแบบนั้นจริง ๆ
    • รู้สึกว่าการแก้นี้ถูกประเมินต่ำไปหน่อย พูดตรง ๆ คือมีบรรทัดที่ถูกลบไปพอสมควร และก่อนจะเข้าใจอย่างลึกซึ้งว่าบรรทัดพวกนั้นเดิมตั้งใจจะทำอะไร ผมคงไม่กล้ากดปุ่ม Delete แน่
    • การแก้จริง ๆ ดูเหมือนจะง่ายกว่านั้นอีก เหมือนแค่เพิ่มการตรวจสอบนี้เข้าไปจริง ๆ: !doc->HasFocus(IgnoreErrors())

  • ว้าว ผมนึกมาตลอดว่า somehow เป็นความผิดของผมเอง มันตามหลอกหลอนมาหลายปี ทั้งผ่าน Windows หลายเวอร์ชันและการติดตั้งใหม่หลายครั้ง
    ไม่ได้เกิดบ่อยนัก แต่ก็เกิดสม่ำเสมอพอให้จำได้

    • UI toolkit ที่ไม่ใช่ native ทั้งหมดดูเหมือนจะมีบั๊กเล็ก ๆ น้อย ๆ ในพฤติกรรม tooltip กันทั้งนั้น
    • ลองคิดดูว่า Mozilla จะทำเงินได้เท่าไรถ้าขายพื้นที่โฆษณาบน tooltip ที่ค้างอยู่ตลอด 22 ปีที่ผ่านมา พวกเขาควร ทำเงินจากบั๊ก ของตัวเองก่อนที่คนอื่นจะทำ
    • ใช่เลย ผมนึกว่าตัวเองเริ่มเพี้ยน หรือไม่ก็ใช้ตัวติดตั้งที่อะไรสักอย่างเสียอยู่
    • ผมก็เหมือนกัน นึกว่าเป็นแค่ผม แต่เกิดขึ้นกับทุกเครื่องของผมทั้งบน Linux และ Windows
    • บน macOS ก็เป็นแบบเดียวกันอย่างน้อยหลายปีแล้ว

  • เป็นบั๊กที่น่าสนใจทีเดียว ดูเหมือนหลายคนจะเจอ และบางคนบอกว่าเห็นอย่างน้อยวันละครั้ง แต่ในช่วง 15 ปีที่ผ่านมา ผมจำไม่ได้เลยว่าเคยเห็นพฤติกรรมนี้
    ดูเหมือนไม่ได้จำกัดอยู่ที่ระบบปฏิบัติการด้วย เลยสงสัยจริง ๆ ว่าเงื่อนไขที่ทำให้บั๊กนี้แสดงออกมาคืออะไร
    ที่เดียวที่ผมเคยเห็นบั๊กคล้ายกันคือ LibreWolf ซึ่งเป็น Firefox แบบปรับแต่งเพื่อเพิ่มความเป็นส่วนตัว แต่ผมแทบมั่นใจว่าเป็นเพราะ flatpak มากกว่าจะเป็นตัวเบราว์เซอร์เอง Firefox ตัวอื่น ๆ ที่ผมรันไม่เคยมีพฤติกรรมแบบนั้น

    • บั๊กแบบนี้ดูจะพบได้ค่อนข้างทั่วไปในระบบ GUI หลายแบบ ตัวอย่างเช่น ผมเห็นพฤติกรรมแบบนี้บ่อยมากบน taskbar ของ Windows 10 และวิธีเดียวที่จะออกจากมันได้คือเอาเคอร์เซอร์ไปวางบนปุ่มหน้าต่างแบบกลุ่ม แล้วเลื่อนออกจาก taskbar
      เว็บไซต์จำนวนมากก็เกิดปัญหาคล้ายกันได้ถ้าเงื่อนไขลงตัว
      สาเหตุหลักดูเหมือนเป็น ความไม่สอดคล้องในการส่งต่ออีเวนต์ ควรจะได้รับอีเวนต์ตอนเคอร์เซอร์ออกไป แต่บางครั้งก็ไม่ได้รับ เช่น เพราะหน้าต่างเสียโฟกัสไปแล้วจึงไม่ได้รับ mouse event อีกต่อไป
      ถ้าไม่มีวิธีเฉพาะที่ตรวจจับกรณีแบบนี้ได้อย่างเสถียร เช่น DOM onmouseleave หรือ onmouseout ก็ต้องใช้วิธีเลี่ยงและแฮ็กต่าง ๆ เช่น สร้างอีเวนต์สังเคราะห์เมื่อหน้าต่างเสียโฟกัส
    • ผมติดตั้งแบบ native บน OpenSuse Tumbleweed ใน Linux KDE Plasma แล้วเห็นทุกวัน ส่วนใหญ่วันละหลายครั้งด้วย
      อธิบายให้ดีที่สุดคือมันเกิดเมื่อสลับไปยัง เดสก์ท็อปเสมือน อื่นด้วยคีย์ลัดในเฟรมเดียวกับที่ tooltip กำลังเด้งขึ้นมาพอดี
      มันเป็น race condition ที่ต้องการจังหวะเวลาค่อนข้างแม่นมาก เลยคงยากที่จะไล่ให้แคบลง อีกทั้งมักกระทบคนที่ใช้คีย์ลัดเยอะ ๆ เป็นหลัก จึงเป็นไปได้มากว่าหลายคนไม่ได้รับผลกระทบ
      ดีใจมากที่แก้แล้ว และตั้งตารอที่จะได้ Firefox เวอร์ชันนั้น
      เพิ่งลองทดสอบดู การทำซ้ำทำได้แค่วางเมาส์เหนือเป้าหมายของ tooltip แล้วก่อนที่ป๊อปอัปจะขึ้น ให้สลับไปเดสก์ท็อปเสมือนอื่นในขณะที่ Firefox ไม่ใช่แอปพลิเคชันที่ active ใหม่
    • เป็นบั๊กที่ เฉพาะกับ workflow มาก ๆ ผมแทบจะเจอเฉพาะตอนเล่นวิดีโอเกมเท่านั้น
      ระหว่างเล่นเกม ผมมักเปิดวิดีโอ YouTube ไว้ในแท็บหนึ่งของเบราว์เซอร์ และหา ข้อมูลเกี่ยวกับเกมในอีกแท็บหนึ่ง
      ดังนั้นก่อน Alt-Tab กลับเข้าเกม มักจะมีการโต้ตอบกับแถบแท็บ และตอนนั้น tooltip ก็ถูกทริกเกอร์
      ระหว่างการใช้งานเบราว์เซอร์ทั่วไป เคอร์เซอร์แทบจะอยู่เหนือเนื้อหาเว็บไซต์เสมอ ซึ่งตรงนั้น tooltip เกิดขึ้นไม่บ่อย
    • ผมเจอบั๊กนี้บ่อยตอนโต้ตอบกับวิดีโอ YouTube ที่ฝังอยู่ในเว็บเพจอื่น
      ลำดับเป็นแบบนี้: พอวางเคอร์เซอร์บนปุ่มควบคุมเต็มหน้าจอของ embedded player ก็จะมี tooltip “Full screen (f)” ขึ้นมา แล้วเมื่อคลิกปุ่มควบคุม วิดีโอจะเข้าสู่โหมดเต็มหน้าจอ แต่ tooltip ยังติดอยู่บนวิดีโอที่กำลังเล่น
      ใช้ตัวจัดการหน้าต่าง Marco ของ MATE บน Linux X11
    • ในเกมก็คล้ายกัน พอมีเกมจากสตูดิโอที่ขึ้นชื่อเรื่องผลงาน “พัง ๆ” ออกมา คนก็จะโพสต์รวมเหตุการณ์แปลก ๆ ที่เกิดขึ้น แต่ฝั่งผมไม่เคยเกิดอะไรแบบนั้นเลย อาจเป็น ภูมิต้านทานบั๊ก โดยกำเนิดก็ได้
      แต่ผมมักเจอบั๊กที่ไม่เป็นอันตรายอย่างหนึ่ง คือพอเปิดเมนูส่วนขยายของแถบเครื่องมือบุ๊กมาร์ก หรือไอคอน >> มุมขวาบน มันแสดงบุ๊กมาร์กทั้งหมดเป็นรายการดรอปดาวน์ แทนที่จะแสดงเฉพาะบุ๊กมาร์กที่ไม่ได้แสดงบนแถบเครื่องมือ

  • น่าสนใจที่บั๊กนี้ถูกลงทะเบียนไว้ก่อน Firefox เวอร์ชันแรกจะออกเสียอีก: https://en.wikipedia.org/wiki/Firefox_early_version_history
    น่าประทับใจที่ยังรักษาประวัติใน bug tracker ให้ใช้งานได้ยาวนานขนาดนี้

    • ประวัติของ bug tracker อาจสืบต่อมาตั้งแต่ยุค Phoenix/Firebird ก็เป็นได้

  • โอ้ ในที่สุด บั๊กที่เกี่ยวข้องคือ https://bugzilla.mozilla.org/show_bug.cgi?id=1569439 ถูกปิดไปเมื่อ 9 เดือนก่อน และเพราะอย่างนั้นมันก็ดีขึ้นเล็กน้อย
    บั๊กนั้นเป็นแค่ปัญหาที่ tooltip ไม่หายไปเมื่อสลับไปยังแอปอื่น แต่พอสลับไปยัง workspace อื่น มันก็ยังค้างอยู่ เลยน่าผิดหวังมาก
    ข้อเสียคือ นี่เป็นการแก้ที่ค่อนข้าง “ผิดทาง” tooltip ควรจะแสดงได้แม้หน้าต่างไม่มีโฟกัส อย่างน้อยในแอป GTK บน Linux ก็เป็นแบบนั้น และ Firefox ก็พยายามเลียนแบบพฤติกรรมนั้น
    ควรแก้ที่ สาเหตุราก ที่ทำให้ tooltip ไม่หายไปเมื่อเปลี่ยน workspace จนตัวชี้เมาส์ไม่ได้อยู่เหนือหน้าต่างจริง ๆ อีกต่อไป

    • สิ่งที่ผมเจอบ่อยที่สุดไม่ใช่บั๊กใน TFA แต่เป็นบั๊กที่เกี่ยวข้องอันนั้น ไม่ได้เห็นมาพักหนึ่งแล้ว ตอนนี้รู้แล้วว่าทำไม

  • ลิงก์แพตช์โดยตรง: https://hg.mozilla.org/mozilla-central/rev/8ae372dc88d1

    • นี่คือ commit ใช่ไหม?
      ถ้าใช่ การใส่ทั้ง การเปลี่ยน indentation กับการเปลี่ยนโค้ดจริงไว้ใน commit เดียวกันนี่เป็นเรื่องปกติหรือเปล่า?
      โดยส่วนตัว ผมน่าจะ commit การเปลี่ยน indentation ก่อน แล้วค่อยทำการเปลี่ยนโค้ดใน commit ที่สอง
    • ว้าว ถ้าไม่นับบรรทัดที่เปลี่ยนเพราะการเปลี่ยน indentation แล้ว การเปลี่ยนแปลงนี้มีโค้ดใหม่แค่ห้าบรรทัดเอง!