Lỗi Firefox `<textarea>` được sửa sau 25 năm

 (bugzilla.mozilla.org)
1 điểm bởi GN⁺ 2024-05-23 | 1 bình luận | Chia sẻ qua WhatsApp
  • Bug 33654 lâu năm của Firefox là lỗi khiến <textarea> khi áp dụng ROWS= và COLS= bị cộng thêm cả phần không gian dành cho thanh cuộn, nên hiển thị lớn hơn số hàng·cột đã chỉ định; hiện đã được đóng là bản trùng của Bug 1830576
  • Trong môi trường tắt overlay scrollbars hoặc dùng thiết lập “always show scrollbars”, hiện tượng <textarea rows=N> bị tính thành chiều cao khoảng N+1 hàng lặp lại nhiều lần
  • Thảo luận ban đầu dần mở rộng sang việc kế thừa phông chữ, ép dùng monospace, cách tính cols dựa trên độ rộng trung bình của w và W, cho đến cách chừa sẵn không gian cho thanh cuộn; testcase·patch·ảnh chụp màn hình được tích lũy trong thời gian dài
  • Trên thực tế, rows=1 có thể trông như 3 hàng hoặc rows=2 hiển thị với chiều cao 3 hàng; ở cols=80, vị trí xuống dòng giữa IE và Firefox cũng khác nhau, khiến việc kiểm soát bố cục biểu mẫu bị lệch tùy theo trình duyệt
  • Khi Bug 1830576 được đánh dấu VERIFIED FIXED, cách áp dụng khoảng trống cho thanh cuộn giữa WebKit, Chromium và Firefox đã trở nên nhất quán, còn Bug 33654 được chốt là RESOLVED DUPLICATE

Trạng thái và phạm vi của Bug 33654

  • Bug 33654 là lỗi khiến <textarea> áp dụng sai ROWS= và COLS=, tạo ra phần không gian bổ sung cho thanh cuộn theo chiều ngang·dọc khi overlay scrollbars bị vô hiệu hóa
  • Sản phẩm và thành phần là Core :: Layout: Form Controls, bao gồm bố cục và giao diện của các điều khiển biểu mẫu HTML, đặc biệt là các phần tử như textarea
  • Trạng thái hiện tại là RESOLVED DUPLICATE of bug 1830576
    • Tiêu đề của Bug 1830576, bug bị trùng, là Firefox sizes <textarea rows=N> as roughly N+1 rows tall, under an "always show scrollbars" configuration
    • Trạng thái của Bug 1830576 là VERIFIED FIXED
  • Bug này được mở từ 26 năm trước và đã được đóng là RESOLVED DUPLICATE từ 2 năm trước
  • Metadata hiển thị phiên bản Trunk, nền tảng x86 / All, loại defect, độ ưu tiên P3, mức độ nghiêm trọng S3
  • Từ khóa là testcase, Whiteboard là [html][behavior]relnote-devel, số phiếu bầu là 99
  • Phần đính kèm hiển thị 17 files, 17 obsolete files; testcase·patch·ảnh chụp màn hình được gửi lên lặp đi lặp lại

Triệu chứng ban đầu

  • Trong báo cáo đầu tiên, Andrew McMillan cho biết ví dụ TEXTAREA được chỉ định ROWS=5 COLS=30 lại hiển thị gần giống ROWS=7 COLS=48
  • Ở các bình luận đầu tiên, có nhiều trường hợp INPUT TYPE=TEXT và TEXTAREA không dùng đúng phông chữ đã chỉ định, hoặc vùng hiển thị quá cao dù thanh cuộn có xuất hiện hay không
  • Sau đó, thảo luận hội tụ ở nhận định rằng layout của textarea đang nhận thông tin sai: số cột có không gian bổ sung, còn số hàng thì bị cộng thêm một
  • Khả năng nguyên nhân đến từ việc chừa sẵn không gian cho thanh cuộn cũng được đề cập từ sớm

Tính toán phông chữ và patch ban đầu

  • Trong một trường hợp ở nhóm tin HTML authoring, khi dùng textarea { font-size: 8pt } cùng với <textarea cols="40" rows="12">, IE render chiều rộng đúng như mong đợi, còn Mozilla trông như đang tính chiều rộng theo phông chữ 12pt
  • Tệp kiểm thử dùng phông arial chứa <textarea NAME=system_code wrap=soft rows=5 cols=30 WRAP style="font-family:arial">
  • Rod cho rằng với phông mặc định thì việc tính kích thước là đúng, nên vấn đề cốt lõi không phải sizing mà là textarea không dùng đúng phông chữ
  • Kin phát hiện khi cờ PlainText của editor được đặt, mã sẽ ép áp dụng font-family: monospace; cho vùng nội dung của TextControl
    • Nếu bỏ đoạn mã này thì phông chữ đúng sẽ được dùng
    • Tuy nhiên, ở chế độ NavQuirks vẫn còn vấn đề: chuỗi 30 ký tự trong textarea 30 cột chỉ chiếm khoảng 2/3 chiều rộng
    • Nguyên nhân được chỉ ra là nsFormControlHelper lấy độ rộng trung bình của w và W từ phông chữ, nhân với số cột rồi cộng thêm độ rộng thanh cuộn để tính chiều rộng textarea
  • Patch to use the correct font. thêm eEditorEnableWrapHackMask vào cờ khởi tạo plain text editor và giới hạn có điều kiện việc áp dụng font-family: monospace;
  • Patch này từng được xử lý là RESOLVED FIXED, nhưng sau đó được mở lại khi người báo cáo ban đầu cho biết COLS=... đã đúng còn ROWS=... vẫn hoạt động sai

Tái hiện lặp lại và các bug trùng

  • Danh sách bug trùng có nhiều trường hợp <textarea> trông cao hơn một dòng so với số hàng được chỉ định, hoặc rows=1 hiển thị như 3 dòng
    • 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 là một tài liệu HTML 4.01 Strict cho phép thay đổi giá trị rows và cols bằng nút bấm, không dùng font tag hay phông biến độ rộng
    • Kết quả hoạt động là luôn nhiều hơn 3 cột so với giá trị chỉ định, còn số hàng thì thường nhiều hơn 1
    • Nếu yêu cầu rows=1 thì sẽ hiển thị 3 hàng
  • Ở các trunk build Linux và Win2000 năm 2002, đã có trường hợp <textarea cols=40 rows=2></textarea> hiển thị thành 3 hàng, và rows=N thì hiển thị chính xác N+1 hàng
  • Bộ kiểm thử W3C HTML 4.01 cũng được dùng làm tài liệu tham khảo, với bình luận rằng lỗi hiện rõ trong bài kiểm thử liên quan đến ROWS
  • Trên Windows 2000 và Mozilla 0.9.3, cũng có ví dụ cho thấy textarea rows=1 rõ ràng không trông như chỉ có 1 hàng

Thảo luận về cách tính không gian thanh cuộn

  • Comment 86 giải thích rằng kích thước textarea được tính bằng giá trị cols/rows chỉ định cộng thêm không gian cho thanh cuộn
  • Khác với IE, Mozilla chỉ hiển thị thanh cuộn khi cần, nên người dùng cảm thấy đây là hành vi bị lỗi
  • Ba lựa chọn khả dĩ đã được đề xuất
    • Không cộng kích thước thanh cuộn khi tính kích thước textarea
    • Luôn hiển thị thanh cuộn như IE
    • Chỉ tính phần thanh cuộn sẽ hiển thị
  • Lựa chọn thứ ba bị chỉ ra là có tính vòng lặp: kích thước phụ thuộc vào việc có hiển thị thanh cuộn hay không, trong khi việc hiển thị thanh cuộn lại phụ thuộc vào kích thước
  • Comment 87 đề xuất lựa chọn thứ tư: ROWS và COLS chỉ điều khiển kích thước phần nội dung của textarea, còn khi thanh cuộn xuất hiện thì textarea sẽ tự lớn ra
  • Sau đó, hướng triển khai được thảo luận là reflow với width/height không có thanh cuộn để xác định có cần thanh cuộn không, rồi nếu cần thì reflow lại với width/height mới

Ảnh hưởng người dùng nhìn thấy

  • Khi chỉ định rows="2" mà lại xuất hiện textarea cao 3 hàng, ý đồ hướng dẫn trực quan về lượng nội dung cần nhập bị mờ đi
    • Một web application yêu cầu đoạn tóm tắt ngắn và dùng rows="2" để gợi ý lượng nhập kiểu “nhiều hơn một dòng nhưng không phải bài luận”
    • Do khác biệt giữa Firefox, IE6 và Opera 8, cùng một giá trị rows lại tạo ra hướng dẫn trực quan khác nhau tùy user agent
  • Ngay cả khi nội dung textarea không cuộn, vẫn có nhiều bình luận cho rằng hành vi của Firefox là sai
    • Với các ô nhập như địa chỉ, thường không vượt quá ba dòng, ngay cả khi đặt rows="3" Firefox vẫn luôn hiển thị thêm một hàng
    • Trang trở nên cao không cần thiết, và người dùng có thể nghĩ rằng vì ô lớn hơn dự kiến nên họ chưa điền đủ thông tin
  • Ở so sánh cols=80, mô tả ảnh chụp màn hình cho thấy IE lấp đầy đủ 80 ký tự 1 tới sát mép thanh cuộn rồi mới xuống dòng, còn Firefox sau 80 ký tự 1 vẫn còn chỗ cho thêm 2 ký tự và sau đó mới xuất hiện thanh cuộn ngang
  • Đến năm 2019 vẫn còn bình luận cho biết vấn đề chưa biến mất, và thẻ Trello Chat bar is a line taller than usual on Firefox của Discord được nêu như một ví dụ bị ảnh hưởng

Những nỗ lực vá lỗi kéo dài nhiều năm

  • Hideo Saito đã nhiều lần đính kèm patch và testcase
    • patch for rows and cols
    • testcase patch wrap="off"
    • base patch
    • additional patch for another bug
    • patch which does not remove space
  • Một hướng tiếp cận là để nsTextControlFrame::Reflow chạy với intrinsic size loại trừ thanh cuộn, rồi nếu có thanh cuộn thì cộng kích thước thanh cuộn vào intrinsic size và reflow lại
  • Cách sửa GetScrollbarStyles để text control frame kiểm soát việc thanh cuộn ở chế độ auto, hidden, hay scroll cũng được bàn tới
  • roc thích phương án xử lý trong nsTextControlFrame hơn là đưa quá nhiều thay đổi vào nsGfxScrollFrame
  • Các patch về sau liên tục lặp lại vòng review và làm lại quanh các cơ chế như SetScrollbarStyles, GetScrollbarStyles, SetScrollbarSpace, GetScrollbarOverflowState, FrameNeedsReflow, callback hậu reflow
  • Một số patch nhận review- hoặc bị đánh dấu obsolete; reviewer lưu ý cần cập nhật cho phù hợp với trunk

Cách né tạm thời và giới hạn

  • Có đề xuất rằng thêm CSS textarea{ overflow-x: hidden } sẽ giải quyết được vấn đề
  • Tuy vậy, cách này chỉ áp dụng khi không cần thanh cuộn ngang
  • Một bình luận khác phản bác rằng bug này không thể sửa chỉ bằng CSS overflow, và Firefox là trình duyệt duy nhất render textarea dư thêm một dòng
  • Emilio Cobos Álvarez nói nguyên nhân có vẻ đến từ kích thước thanh cuộn, và việc áp dụng scrollbar-width: none cho <textarea> dường như giải quyết được
  • Cùng bình luận đó cũng nói thêm rằng bản thân bug vẫn nên được sửa đúng cách

Kết luận cuối cùng

  • 3 năm trước, BugBot cho biết bug này có mức độ nghiêm trọng tương đối thấp là S3, nhưng có 27 bug trùng, 103 phiếu bầu và 91 người trong CC, nên đề nghị xem xét nâng severity
  • Tóm tắt bug được đổi từ TEXTAREA incorrectly applying ROWS= and COLS= thành TEXTAREA incorrectly applying ROWS= and COLS= (horizontal / vertical scrollbar extra space, with overlay scrollbars disabled)
  • Daniel Holbert thêm Bug 1830576 Firefox sizes <textarea rows=N> as roughly N+1 rows tall, under an "always show scrollbars" configuration làm dependency
  • Luke Warlow hỏi liệu có thể đóng bug này không, vì Bug 1830576 đã được sửa nên cách áp dụng khoảng trống cho thanh cuộn giữa WebKit, Chromium và Firefox đã nhất quán
  • Emilio Cobos Álvarez đồng ý, và Bug 33654 được chuyển từ NEW sang RESOLVED rồi đóng là DUPLICATE
  • Bug trùng được chỉ định là Bug 1830576, và bug đó hiện ở trạng thái VERIFIED FIXED

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-05-23
Ý kiến trên Hacker News

  • Ha! Tôi đã theo dõi lỗi này trong phần lớn 25 năm đó. Hồi ấy chưa có Firefox, và lỗi này được ghi nhận ở phía Mozilla trước/sau đó chứ không phải Netscape Navigator
    Tôi không nhớ vì sao mình theo dõi, nhưng có lẽ là vì đã bình luận. Cứ vài năm lại có email thông báo nên lúc nào cũng thấy buồn cười, và vài ngày trước cuối cùng nó đã được sửa

    • Thật ngạc nhiên là trạng thái theo dõi luồng lỗi đó vẫn sống sót qua ngần ấy năm
    • Tôi cũng tương tự. Hồi mới bắt đầu cân nhắc làm nghề xây dựng website, tôi nhớ mình từng mê mẩn khi tưởng tượng các website có nền trong suốt hoặc bán trong suốt nhìn xuyên tới tận desktop
      Tôi luôn nghĩ rằng viết kiểu html { background: transparent; } thì đáng lẽ cứ thế phải chạy. Tuy nhiên bản sửa lỗi lần này thực ra không làm điều đó. Trước hết, đây không phải tính năng website mặc định chọn, mà là một thiết lập người dùng hoặc extension có thể bật. Có lẽ như vậy tốt hơn, vì nếu cho phép mặc định thì đã mở ra một con đường mới cho clickjacking
    • Không hẳn là “được ghi nhận nhắm tới Netscape Navigator”, mà đúng hơn là phía Mozilla Suite. Năm 2000 thì đã khá sâu trong thời Mozilla rồi, và tôi cũng không nghĩ lỗi của Netscape lại được đưa vào Bugzilla
    • Wow, lỗi này còn lâu đời hơn cả bản thân Firefox
    • Tiếp theo sẽ đến lượt ticket phiên bản liên dự án của Jira được giải quyết

  • Hơi lạc đề một chút, nhưng tôi thật sự ghét trào lưu hiển thị khoảng thời gian dễ đọc cho con người kiểu “một tháng trước”. Cứ hiển thị ngày tháng đi, tôi tự tính được
    Outlook, ít nhất là bản Mac, là tệ nhất. Email trước hôm nay chẳng hạn chỉ hiện mỗi “hôm qua”, và phải bấm vào email mới thấy cả giờ. Mỗi ngày tôi nhận hàng chục email, nên nếu 50 tin nhắn liên tiếp chỉ toàn hiện “hôm qua” thì hoàn toàn vô dụng

    • Sẽ tốt nếu di chuột lên phần hiển thị dễ đọc đó thì hiện ra timestamp chính xác
    • Thật lòng mong trào lưu này sớm biến mất. Một email đến lúc 6 giờ sáng hay 11 giờ đêm trong ngày đó là khác nhau rất lớn. Chỉ nói “hôm qua” là không đủ
      Bia thì nên lạnh, timestamp thì nên chính xác
    • Còn tệ hơn nếu nó sai nữa. Discogs cứ khăng khăng gọi tháng 10/2021 là “hơn 3 năm trước”
    • “Cứ hiển thị ngày tháng đi, tôi tự tính được” đối với tôi thật sự rất khó. Tôi gặp khá nhiều khó khăn với chính khái niệm ngày tháng hay dòng chảy của thời gian
    • Di chuột lên ngày thì sẽ thấy ngày và giờ chính xác

  • Bugzilla của Firefox chắc chắn là một trong những trình theo dõi lỗi được vận hành lâu đời nhất. Dù đã trải qua vô số lần sửa đổi, thật ấn tượng là nó vẫn còn giữ khá nhiều cảm giác ban đầu. Ngày xưa đó là một codebase khá thô ráp và giống như quái vật
    Khoảng năm 2000, trong một tổ chức phát triển Windows, tôi từng dựng một instance để thay thế trình theo dõi lỗi tự làm dựa trên Microsoft Access/Outlook. Nó phức tạp, nhưng trong một thời gian gần như là trình theo dõi lỗi hàng đầu. FogBugz cũng mới bắt đầu vào khoảng thời gian đó, và tôi nghĩ đội ngũ ấy là một trong những nhóm đầu tiên xem xét nghiêm túc trải nghiệm người dùng

    • Ngay cả bây giờ cũng không dễ vượt qua Bugzilla. Thật ra một số lựa chọn hiện nay tệ hơn Bugzilla đến mức tôi không hiểu nổi vì sao chúng tồn tại. Ví dụ Mantis BT mà Dwarf Fortress dùng thật sự rất tệ
      Ngược lại, FogBugz là công cụ mà tôi luôn muốn thử một lần nếu có dịp

  • Nhìn những chuyện như thế này thấy ấm lòng. Gần đây tôi cũng trải qua chuyện tương tự với một lỗi Firefox 24 năm tuổi: https://bugzilla.mozilla.org/show_bug.cgi?id=62151

    • Chết tiệt, tôi nhớ mình từng bị kẹt và loay hoay vì cái này

  • Trong số các lỗi tồn đọng lâu năm, điều gây khó chịu nhất là trong LibreOffice không thể định dạng đúng trục x của biểu đồ phân tán dưới dạng ngày tháng
    https://bugs.documentfoundation.org/show_bug.cgi?id=54132
    Đây là lỗi 12 năm tuổi. Nhìn các bình luận thì có vẻ mọi người ngại sửa vì code quá “phức tạp kinh khủng”, và nếu sửa thì rất có thể gây hồi quy

    • Tôi từng hy vọng LibreOffice sẽ mang sang các tính năng tôi thích trong Excel, nhưng thấy chuyện này thì kỳ vọng giảm đi
    • Nếu chỉ cần bảng tính và gói vẽ biểu đồ, trên Linux gnumeric là một lựa chọn tốt
    • Thật thích những lúc maintainer bắt đầu sợ chính đoạn code mà họ đã cho phép merge

  • Lần tới mong họ xử lý XDG. Cái này tôi cũng đã chờ 20 năm rồi [1]
    [1] https://bugzilla.mozilla.org/show_bug.cgi?id=259356

    • Tôi không nghĩ thư mục cơ sở XDG sẽ bao giờ được áp dụng một cách đầy đủ và phổ biến. Đã 21 năm trôi qua rồi. Nếu Arch Linux không tỏ ra quyết liệt với các chương trình không tuân theo nó, chẳng hạn như khóa quyền trên thư mục người dùng root, thì nó cũng đã không lớn mạnh như gần đây
      Thành thật mà nói, đặc tả này không chủ động giải quyết các vấn đề thực tế mà mọi người gặp phải. Phần lớn việc áp dụng là kết quả của việc những người khó chịu với cách tổ chức thư mục $HOME liên tục gây áp lực lên các maintainer, còn 99% người dùng không quan tâm chương trình có tuân theo thư mục cơ sở XDG hay không. Nó chỉ giúp người ta có thể lập luận rằng mọi thứ “gọn gàng hơn” theo một đặc tả freedesktop đã hơn 20 năm vẫn chưa được áp dụng rộng rãi
      Cá nhân tôi không thích cách tách biệt lỏng lẻo giữa cấu hình/dữ liệu/cache và ý định ngầm định của nó. Không phải thứ gì cũng khớp với các nhóm đó, và như vậy hành vi của hệ thống sẽ khó dự đoán hơn. Daemon có xóa cache của tôi không? Người dùng có mang thư mục cấu hình đi sao chép không? Chính xác thì thứ gì sẽ được sao lưu? Đặc tả không có chuẩn nào về việc các thư mục thực sự nên được xử lý ra sao. Nó cố ý mơ hồ, nhưng mơ hồ theo cách có thể làm hỏng mọi thứ nếu người ta đưa ra giả định
      Nó giống như tách /usr khỏi root, tách /usr/local khỏi root, hoặc đặt /opt. Cảm giác như tàn dư của một thời đã qua vẫn tiếp tục tồn tại, rồi lại muốn tạo thêm một cái nữa
      Trong sản phẩm của chúng tôi cũng miễn cưỡng hỗ trợ, nhưng chỉ khi biến môi trường tương ứng được đặt rõ ràng. Khi không được đặt, chúng tôi bỏ qua 100% hành vi của XDG cho rằng mặc định trên mọi hệ thống Linux phải như vậy. Vì nó khác với cách các hệ UNIX khác như MacOS mong đợi. Chúng tôi chỉ thêm vừa đủ để ngăn các fan cuồng Arch Linux kéo vào bug tracker hằng tuần đòi áp dụng, và họ còn chưa tới 1% tổng số người dùng. Chỉ riêng việc viết tài liệu hướng dẫn người dùng tìm file của sản phẩm chúng tôi ở đâu trên hệ thống của họ đã đủ khó rồi. Người dùng không phải lúc nào cũng biết XDG, và với đa số, XDG cũng không phải là một quy ước đã được thiết lập mà họ kỳ vọng. Ngoài những người muốn thư mục người dùng sạch sẽ ra thì nó không có giá trị mạnh mẽ, trong khi di sản cũ quá nhiều để chuyển tất cả mọi người sang đặc tả này
      Thành thật mà nói, nên nghĩ lại toàn bộ và đi theo giải pháp dựa trên container, nơi ứng dụng desktop không thể thoát khỏi cái nhà tù nhỏ của nó. Gần giống như ứng dụng snap vậy. Cũng có thể học một chút từ Nix. Phải thừa nhận rằng việc khiến mọi ứng dụng người dùng Linux trên thế giới quan tâm và áp dụng thư mục cơ sở XDG, thậm chí cả thư mục người dùng, là một thất bại. Chỉ riêng việc hỗ trợ port cho Mac và Windows đã đủ vất vả, mà chúng không tuân theo hành vi này. Cần thoát khỏi mô hình quyền UNIX chạy chương trình dưới quyền người dùng, và chạy mỗi chương trình bằng uid riêng của nó. Android hoạt động như vậy
    • Đúng, tôi cũng đang mong cái đó

  • Mong sao lỗi tùy chọn sao chép bị vô hiệu hóa ngẫu nhiên dù có văn bản để sao chép sẽ được sửa. Thật sự phát điên lên được

    • Mừng là không chỉ mình tôi gặp
    • Để xem có được sửa trong vòng 25 năm không. Với chuẩn môi trường web nhanh như hiện nay, Mozilla đôi khi quá chậm

  • AWS giải quyết vấn đề này bằng cách định kỳ xóa các bug cũ và mọi đề cập đến chúng

    • Đó là chiến lược đà điểu để né bug

  • Bài liên quan hồi tháng 8 năm ngoái:
    Chúc mừng sinh nhật lần thứ 25 của Bugzilla
    https://news.ycombinator.com/item?id=37279543

  • Tuyệt! Nhưng 2000-03-28 vẫn chưa phải là 25 năm trước

    • Nghe vậy thì đúng là cách làm tròn khá lạ
    • Đúng. Thành thật mà nói, nếu là tôi thì chắc đã đợi thêm vài tháng nữa rồi sửa đúng dịp kỷ niệm đám cưới bạc :P