Lỗi tooltip của Firefox được sửa sau 22 năm

 (bugzilla.mozilla.org)
1 điểm bởi GN⁺ 2023-10-11 | 1 bình luận | Chia sẻ qua WhatsApp
  • Lỗi tooltip-ghost khiến tooltip vẫn ở tiền cảnh ngay cả khi Firefox chạy nền đã được theo dõi rất lâu trên Bugzilla, và đã chuyển sang trạng thái VERIFIED FIXED trong nhánh Firefox 119
  • Cách tái hiện ban đầu là di chuột lên liên kết hoặc biểu tượng trên thanh công cụ để hiển thị tooltip, rồi dùng Command-Tab hoặc Alt-Tab để chuyển sang ứng dụng khác thì tooltip không biến mất
  • Các trường hợp tương tự tiếp tục xuất hiện không chỉ trên Mac OS X, Windows, Linux mà còn trong Thunderbird, Sunbird và Lightning; trên Firefox 5.0.1, chỉ cần di chuột qua cửa sổ nền là cũng có thể kích hoạt tooltip và trạng thái mouseover
  • Bản vá cuối cùng là only show tooltip when document has focus, đổi hành vi để chỉ hiển thị tooltip khi tài liệu có focus, và đã được đưa vào mozilla-central ở revision 8ae372dc88d1
  • QA đã tái hiện theo quy trình gốc trên Firefox 106.0.1 và Ubuntu 22.04, sau đó xác nhận sự cố không còn tiếp diễn trên bản dựng Nightly 120.0a1; về sau một số lỗi hồi quy liên quan được liên kết riêng

Tooltip còn treo trên Firefox chạy nền

  • Bug 148624 nói về vấn đề tooltip vẫn nằm ở tiền cảnh ngay cả khi Firefox đang ở nền
  • Tiêu đề gốc là Tooltips persist in foreground when Firefox is in background, bí danh là tooltip-ghost
  • Trạng thái là VERIFIED FIXED, mốc mục tiêu là 119 Branch
  • Phân loại là Core :: XUL, kiểu là defect, mức độ nghiêm trọng là S3

Các bước tái hiện ban đầu và hành vi mong đợi

  • Môi trường được báo cáo đầu tiên là Mozilla/5.0 ... Mac OS X ... Gecko/20020602 BuildID: 2002060203
  • Các bước tái hiện rất đơn giản
    • Di chuột lên biểu tượng thanh công cụ hoặc liên kết
    • Chờ cho tooltip xuất hiện
    • Dùng Command-Tab để đưa Mozilla xuống nền
  • Trên thực tế, hộp tooltip màu vàng nhỏ vẫn tiếp tục nằm ở tiền cảnh
  • Hành vi mong đợi là tooltip phải biến mất khi Mozilla chuyển xuống nền
  • Người báo cáo ban đầu cho biết phải đưa Firefox trở lại tiền cảnh rồi di chuột ra khỏi thanh công cụ thì tooltip mới biến mất

Các trường hợp tái hiện trên nhiều nền tảng

  • Sau xác nhận ban đầu, phạm vi nền tảng đã được đổi từ Mac OS X sang All, và cùng lỗi cũng tái hiện được trên Windows XP và Windows 98
  • Các trường hợp tiếp tục xuất hiện trên 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 v.v.
  • Hiện tượng tương tự cũng xuất hiện trong Thunderbird, Sunbird và Lightning
    • Với Thunderbird 2.0.0.17 và Lightning 0.9, có đính kèm trường hợp tooltip của cửa sổ tác vụ vẫn nằm trên cửa sổ thông báo
    • Với tổ hợp Thunderbird 102.4.1 và Firefox 106.0.1, lỗi cũng được tái hiện trên GNU/Linux
    • Với Firefox 117.0 và Thunderbird 115.2.0 trong môi trường xfce và xfwm, quy trình tái hiện cũng đã được gửi lên
  • Một người dùng cho biết lỗi vẫn xảy ra trên Firefox 115.0.2 và GNOME 44, và đã dùng thiết lập browser.chrome.toolbar_tips để tắt hẳn tooltip như một cách lách tạm thời

Ảnh hưởng vượt ra ngoài tooltip bị kẹt lại

  • Không chỉ tooltip đã hiện sẵn bị kẹt lại, mà còn xác nhận được hiện tượng tooltip mới vẫn xuất hiện nếu trong lúc Firefox đang ở nền, con trỏ chuột đi qua vùng tương ứng của cửa sổ Firefox
  • Trên Firefox 5.0.1, có đính kèm trường hợp khi Transmission ở tiền cảnh còn Firefox ở nền, việc di chuyển chuột trên cửa sổ Transmission Inspector lại kích hoạt tooltip của Firefox
  • Cũng từng có trường hợp tooltip lớn của nút thanh công cụ Adblock Plus hiện chồng lên Transmission
  • Có ghi nhận trường hợp tooltip Options của Transmission và tooltip của ô tìm kiếm Google trong Firefox cùng hiển thị và chồng lên nhau
  • Với các mục trên thanh dấu trang, không chỉ tooltip mà cả trạng thái mouseover cũng bị kích hoạt
    • Trạng thái của nút dấu trang đổi trước, rồi một lúc sau tooltip URL xuất hiện
    • Nút + của Open a New Tab cũng được ghi nhận là ngoại lệ có thể phát sinh trạng thái mouseover và tooltip ngay cả khi ở nền

Hướng sửa và bản vá đã được áp dụng

  • Trong các thảo luận đầu thập niên 2010, đã có đề xuất không hiển thị tooltip nếu cửa sổ không có focus vào thời điểm bộ đếm thời gian tooltip chạy
  • Safari và Google Chrome được dùng làm ví dụ so sánh trên Mac, vì chúng không hiển thị tooltip khi không phải ứng dụng ở tiền cảnh
  • Mô tả bản vá cuối cùng là only show tooltip when document has focus
  • Bản vá được đưa lên dưới dạng tệp đính kèm Phabricator, rồi sau đó được hợp nhất vào autoland và mozilla-central
  • Trạng thái được đổi từ ASSIGNED sang RESOLVED, và kết quả xử lý là FIXED

Xác minh QA và các hồi quy tiếp theo

  • QA đã xác nhận lỗi theo đúng quy trình tái hiện ban đầu trên Firefox 106.0.1 và Ubuntu 22.04
  • Trên cùng cấu hình đó, ở bản Nightly 120.0a1 mới nhất, lỗi không còn tiếp diễn nên trạng thái được đổi thành VERIFIED
  • Trạng thái firefox119 được đổi từ fixed sang verified
  • Một người dùng cho biết lỗi chỉ xuất hiện khi MOZ_ENV_XINPUT2=1 và biến mất khi MOZ_ENV_XINPUT2=0; trường hợp này được liên kết với bug 1809029
  • Về sau các lỗi hồi quy liên quan sau đây đã được liên kết
    • 1857513: tooltip ở thanh bên dấu trang không xuất hiện khi hover nếu thanh bên không có focus
    • 1861427: tooltip không còn xuất hiện khi hover nếu một ứng dụng khác đang được focus
    • 2043757: trên Windows 11, tiêu đề tab không còn hiện khi hover nếu Firefox bị cửa sổ khác che khuất một phần

Bài viết liên quan

1 bình luận

 
GN⁺ 2023-10-11
Ý kiến trên Hacker News

  • Nếu bạn tò mò cách tìm và sửa lỗi trong codebase của Firefox, Mike Conley đã livestream hằng tuần trong vài năm qua về công việc phát triển mà anh ấy làm tại Mozilla
    Phần lớn nội dung đã ghi lại là quá trình chọn một lỗi trong backlog rồi lần theo và xử lý cực kỳ tỉ mỉ
    Đặc biệt khuyến nghị nếu bạn mới bắt đầu lập trình và muốn xem làm việc trên một codebase thực tế trông như thế nào: https://youtube.com/@mikeconleytoronto

    • Thời đại học, tôi đã làm tình nguyện khá nhiều ở Mozilla, vào khoảng thời gian gần như lâu như từ khi lỗi này được đăng ký
      Ban đầu tôi làm phân loại lỗi trong nhóm QA, kiểm tra xem component trong Bugzilla có đúng không, các bước tái hiện có hợp lý không, v.v.
      Dù hoàn toàn chưa có kinh nghiệm thực tế, chỉ riêng việc quan sát một dự án quy mô lớn vận hành ra sao, các nhà phát triển thật sự xử lý bản sửa lỗi và tính năng như thế nào cũng đã học được rất nhiều; tôi cũng tiếp xúc với các khái niệm như diff, patch, CI/CD. Khi đó là nightly build nên nói nghiêm ngặt thì chưa phải tích hợp liên tục, nhưng hướng đi là như vậy
      Sau đó tôi học cách build ứng dụng, đặc biệt trên Windows thì thật sự vất vả. Tôi đã build Firefox, Thunderbird, và cả Mozilla Suite khi đó vẫn còn tồn tại, một dạng tích hợp trình duyệt, email, trình soạn thảo HTML, v.v.
      Cuối cùng tôi cũng đóng góp được vài bản sửa lỗi. Chỉ ở mức sửa lỗi chính tả hay biểu tượng lệch, nhưng cảm giác đoạn code do mình sửa được phát hành cho hàng triệu người dùng thật sự rất lớn
      Kinh nghiệm này giúp ích ngay trong công việc đầu tiên sau khi tốt nghiệp. Tôi bắt đầu ở một startup với vai trò hỗ trợ IT và QA, nơi hoàn toàn không có tự động hóa build và triển khai. Ai đó push lên SVN mà build có hỏng hay không thì có khi vài ngày sau vẫn không biết
      Dựa trên những gì học được ở Mozilla, tôi dùng một thứ gì đó trong số Buildbot, CruiseControl, Hudson để tạo một máy chủ build: build khi có push và gửi email cho nhóm nếu biên dịch hoặc test thất bại
      Việc các lập trình viên giàu kinh nghiệm hỏi “sao người phụ trách IT của chúng ta lại biết mấy thứ này?” khá thú vị, và tôi đã có thể tự tạo ra vai trò kiểu đó từ trước khi có thuật ngữ DevOps. Tất cả là nhờ những gì tôi học được khi mày mò Mozilla trong thời gian rảnh
      Vì vậy tôi hoàn toàn đồng ý rằng hack thử dự án Mozilla là một cách tốt để có kinh nghiệm thực tế

  • Cuối cùng cũng được sửa. Mong Mozilla làm nhiều việc như thế này hơn
    Một trong những dạng khó chịu nhất của lỗi này là khi chạy game toàn màn hình, con trỏ chuột bị đặt lại vị trí làm tooltip hiện ra, rồi nó nổi lên trên game
    Game không thích bị mất focus và Alt-Tab để xử lý Firefox, nên đôi khi rốt cuộc phải khởi động lại game

    • Đúng lúc này tôi đang nghe bài nói chuyện của Jonathan Blow tại DevGAMM 4 năm trước, và kiểu lỗi này xuất hiện như một motif lặp lại
      https://www.youtube.com/watch?v=ZSRHeXYDLko&t=2729s
    • Tôi vẫn đang chờ hành vi cơ bản của container tab được sửa. Khó tránh khỏi cảm giác quản lý sản phẩm đã hỏng hoàn toàn
      [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1479858
    • Tôi nhớ vài năm trước từng bình luận vào bug theo kiểu “tôi cũng gặp và có thông tin này”
      Cuối cùng, khoảng 10 năm trước tôi đã bỏ hẳn Firefox; lý do chính là lỗi này gây khó chịu nhiều lần mỗi ngày trong suốt nhiều năm, và vào khoảng đó Chrome đã đủ tốt để thay thế
      Nội dung tooltip cũng thường khá chung chung như “Previous”, nên tôi gần như phải focus lại từng cửa sổ Firefox để tìm xem nó đến từ đâu, và lúc nào cũng rất cực khi phải dò cho đến khi tooltip đó biến mất. Hơn nữa nó còn nổi trên tất cả các cửa sổ

  • Điều còn đáng ngạc nhiên hơn là trong suốt nhiều năm đó, hành vi này thậm chí không vô tình thay đổi. Đúng là tương thích ngược với bug ấn tượng

  • Tôi luôn đổ lỗi lỗi này cho nhiều trình quản lý cửa sổ desktop trên Linux, giờ mới biết thủ phạm lúc nào cũng là cùng một thứ
    Trên màn hình nhỏ, đôi khi khá phiền vì nó có thể che mất biểu mẫu hoặc các yếu tố quan trọng khác
    Tôi mong chờ bản cập nhật, và hy vọng trong 22 năm tới Firefox không chỉ sạch lỗi mà còn trở lại là một ứng dụng có tầm ảnh hưởng như trước

    • Dù vậy có lẽ tôi vẫn sẽ tiếp tục đổ lỗi cho trình quản lý cửa sổ. Tôi chắc chắn đã thấy nó cả bên ngoài Firefox, thậm chí bên ngoài Linux
    • Nó cũng xảy ra trên Windows, và tiếp tục xảy ra ở các ứng dụng khác trên nhiều hệ điều hành. Không thể chỉ đổ lỗi cho một component hay một tầng GUI cụ thể
    • Hình như tôi cũng đã thấy trong LibreOffice
    • Nó cũng xảy ra ở nơi khác. Tôi thường thấy trong DBeaver
    • Tôi cũng gặp thường xuyên trong Chrome trên Fedora/GNOME/X.Org

  • https://phabricator.services.mozilla.com/rMOZILLACENTRAL8ae3...
    Nếu nhìn vào bản sửa chỉ năm dòng để khắc phục lỗi này và nghĩ “mình cũng làm được!”, thì thực ra đúng là bạn đã có thể làm được
    Câu hỏi thật sự là “vì sao mình không làm?”
    Tự trả lời thì mấu chốt nằm ở việc biên dịch Firefox và chạy bộ kiểm thử dễ đến mức nào
    Quy trình truy vết lỗi dài sau đó mới là phần thú vị

    • Tôi thường đóng góp cho phần mềm mình dùng hằng ngày và cũng từng định làm gì đó cho Firefox, nhưng với người ngoài thì quá khó nên tôi bỏ cuộc
      Toàn bộ hệ thống gồm hg, nhiều kho lưu trữ, wiki cũ, quy trình build cực kỳ phức tạp, Bugzilla, v.v. khiến việc bắt đầu quá khó
      Nếu Firefox nằm trên GitHub, hoặc ít nhất là GitLab tự host, để chỉ cần fork, vọc thử và chạy cùng CI thì câu chuyện đã hoàn toàn khác. Ước gì nó dễ như vậy
    • Có vẻ bản sửa này đang bị đánh giá thấp. Nói thật thì có khá nhiều dòng bị xóa, và trước khi hiểu sâu những dòng đó vốn định làm gì, tôi đã không đủ tự tin để bấm phím Delete
    • Bản sửa thực tế trông còn đơn giản hơn thế. Thật sự chỉ là thêm đúng một phép kiểm tra này: !doc->HasFocus(IgnoreErrors())

  • Chà, tôi luôn nghĩ không hiểu sao đó là lỗi của mình. Nó theo tôi suốt nhiều năm qua nhiều phiên bản Windows và nhiều lần cài lại
    Không xảy ra thường xuyên, nhưng vẫn đều đặn đủ để nhớ

    • Có vẻ mọi bộ công cụ UI không native đều có hành vi tooltip bị lỗi rất tinh vi
    • Tôi tự hỏi nếu Mozilla bán không gian quảng cáo trên các tooltip bị kẹt suốt 22 năm qua thì họ đã kiếm được bao nhiêu tiền. Lẽ ra họ nên kiếm tiền từ bug của mình trước khi ai đó làm vậy
    • Đúng vậy. Tôi cứ tưởng mình phát điên, hoặc đang dùng một bản cài đặt bị hỏng nào đó
    • Tôi cũng vậy. Tưởng chỉ mình tôi bị, nhưng nó xảy ra trên tất cả máy Linux và Windows của tôi
    • Trên macOS cũng vậy ít nhất trong vài năm

  • Đây là một lỗi khá thú vị. Có vẻ rất nhiều người gặp phải, có người nói thấy ít nhất một lần mỗi ngày, nhưng trong 15 năm qua tôi không nhớ mình từng thấy hành vi này lần nào
    Nó cũng có vẻ không bị giới hạn theo hệ điều hành, nên tôi tò mò điều kiện thực sự khiến lỗi này lộ ra là gì
    Nơi duy nhất tôi từng thấy lỗi tương tự là LibreWolf, tức bản Firefox tùy biến tăng cường quyền riêng tư. Nhưng tôi gần như chắc chắn đó là do flatpak chứ không phải do chính trình duyệt. Các Firefox khác tôi chạy chưa bao giờ có hành vi như vậy

    • Loại bug này có vẻ khá phổ biến trong nhiều hệ thống GUI. Ví dụ tôi thấy hành vi này rất nhiều trên thanh tác vụ Windows 10, và cách duy nhất thoát ra là đưa con trỏ lên nút nhiều cửa sổ rồi kéo ra khỏi thanh tác vụ
      Nhiều website cũng gặp vấn đề tương tự nếu đủ điều kiện
      Nguyên nhân chính có vẻ là sự không nhất quán trong truyền sự kiện. Khi con trỏ rời đi thì phải nhận được sự kiện, nhưng đôi khi lại không nhận được, chẳng hạn vì cửa sổ mất focus nên không còn được truyền sự kiện chuột nữa
      Nếu không có một cách chuyên dụng để phát hiện đáng tin cậy các trường hợp này, như DOM onmouseleave hay onmouseout, thì cần workaround và hack. Chẳng hạn có thể tạo sự kiện tổng hợp khi cửa sổ mất focus
    • Tôi cài native trên OpenSuse Tumbleweed với Linux KDE Plasma và thấy hằng ngày, thường là nhiều lần mỗi ngày
      Mô tả sát nhất là nó xảy ra khi chuyển sang desktop ảo khác bằng phím tắt đúng vào frame tooltip xuất hiện
      Có vẻ đây là một race condition cần thời điểm rất chính xác, nên khó khoanh vùng. Vì chủ yếu dính với những người dùng nhiều phím tắt, nhiều người có thể không bị ảnh hưởng
      Tôi thật sự rất vui vì nó đã được sửa, và mong sớm nhận được phiên bản Firefox đó
      Vừa thử lại thì chỉ cần đặt chuột lên đối tượng có tooltip rồi, trước khi popup xuất hiện, chuyển sang desktop ảo khác trong lúc Firefox không phải ứng dụng đang hoạt động mới là tái hiện được
    • Đây là bug rất đặc thù theo quy trình làm việc. Tôi gần như chỉ gặp khi chơi video game
      Khi chơi game, tôi thường mở video YouTube ở một tab trình duyệt, còn tab khác thì tra thông tin liên quan đến game
      Vì vậy tôi hay tương tác với thanh tab ngay trước khi Alt-Tab sang game, và lúc đó tooltip bị kích hoạt
      Trong lúc dùng trình duyệt thông thường, con trỏ hầu như luôn ở trên nội dung website, nơi tooltip hiếm khi xuất hiện
    • Tôi gặp lỗi này nhiều khi tương tác với video YouTube được nhúng trong trang web khác
      Luồng là thế này. Khi đưa con trỏ lên nút toàn màn hình của trình phát nhúng, tooltip “Full screen (f)” hiện ra; bấm nút đó thì video chuyển sang toàn màn hình nhưng tooltip vẫn nằm nguyên trên video đang phát
      Tôi dùng trình quản lý cửa sổ Marco của MATE trên Linux X11
    • Với game cũng tương tự. Khi một game của studio nổi tiếng với các tựa “hỏng” ra mắt, mọi người đăng các compilation về những chuyện kỳ lạ xảy ra, nhưng phía tôi thì chẳng bao giờ gặp. Có lẽ tôi có khả năng kháng bug bẩm sinh
      Tuy nhiên tôi thường gặp một bug vô hại: khi mở menu mở rộng của thanh công cụ dấu trang, tức biểu tượng >> ở góc trên bên phải, danh sách thả xuống hiển thị tất cả dấu trang thay vì chỉ các dấu trang không hiện trên thanh công cụ

  • Thú vị là bug này được đăng ký trước cả khi phiên bản Firefox đầu tiên ra đời: https://en.wikipedia.org/wiki/Firefox_early_version_history
    Thật ấn tượng khi họ giữ cho lịch sử trình theo dõi bug hoạt động lâu đến vậy

    • Có thể lịch sử trình theo dõi bug đã được tiếp nối từ thời Phoenix/Firebird

  • Ồ, cuối cùng cũng xong. Lỗi liên quan https://bugzilla.mozilla.org/show_bug.cgi?id=1569439 đã được đóng 9 tháng trước, và nhờ vậy tình hình có khá hơn một chút
    Lỗi đó chỉ đơn giản là tooltip không biến mất khi chuyển sang ứng dụng khác. Nhưng khi chuyển sang workspace khác thì nó vẫn còn đó, nên cực kỳ thất vọng
    Điểm trừ là bản sửa này ở mức nào đó là một cách sửa “sai”. Tooltip vẫn nên hiện ngay cả khi cửa sổ không có focus. Ít nhất là trong các ứng dụng GTK trên Linux thì như vậy, và Firefox cũng cố bắt chước hành vi đó
    Cần sửa nguyên nhân gốc rễ khiến tooltip không biến mất khi workspace thay đổi và con trỏ chuột thực sự không còn nằm trên cửa sổ nữa

    • Thứ tôi gặp thường xuyên nhất không phải lỗi trong TFA mà là lỗi liên quan đó. Đã một thời gian không thấy nữa, giờ thì tôi biết lý do rồi

  • Liên kết trực tiếp tới bản vá: https://hg.mozilla.org/mozilla-central/rev/8ae372dc88d1

    • Đây có phải là commit không?
      Nếu vậy thì việc đưa thay đổi thụt lề và thay đổi mã thực tế vào cùng một commit có phổ biến không?
      Cá nhân tôi có lẽ sẽ commit thay đổi thụt lề trước, rồi sau đó commit thứ hai cho thay đổi mã
    • Chà, nếu loại trừ những dòng bị thay đổi do chỉnh thụt lề trong commit, thay đổi này chỉ có năm dòng mã mới!