Quay lại
Vì sao Safari và Firefox phải “vá riêng” cho TikTok, Netflix hay Instagram, còn Chrome thì không?
Tin tức

Vì sao Safari và Firefox phải “vá riêng” cho TikTok, Netflix hay Instagram, còn Chrome thì không?

Một số trình duyệt chứa những đoạn code kiểm tra domain mà bạn đang truy cập rồi thay đổi cách trang web được render dựa trên điều đó. Đúng vậy, bạn không đọc nhầm đâu. Kiểu như: nếu `site == X` thì làm `Y`. TikTok được xử lý theo cách riêng. Netflix cũng vậy. Instagram cũng thế. Và cả SeatGuru nữa. Safari và Mozilla Firefox đều làm điều này. Nhưng Google Chrome thì không. Điều đó nói lên một điều khá thú vị.

OmniTwo Team14 tháng 5, 202614 phút đọc39 lượt xem

Nhiều người nghĩ rằng trình duyệt chỉ đơn giản render HTML theo web standards. Nhưng thực tế phức tạp hơn rất nhiều. Các browser hiện đại chứa hàng nghìn đoạn xử lý đặc biệt dành riêng cho từng website cụ thể.

Những điều kiện này thường có dạng:

  • “Nếu người dùng đang ở domain này thì render khác đi.”
  • “Nếu API kia được gọi trên site nọ thì đổi behavior.”
  • “Nếu video thuộc nền tảng kia thì đừng pause như mặc định.”

Đây không phải bug ngoài ý muốn. Nó là một phần cố hữu của cách web hiện đại vận hành, được ship tới hàng tỷ thiết bị.

Source code của các cơ chế này hoàn toàn công khai. Bạn có thể xem chúng trong WebKit hoặc hệ thống compatibility intervention của Firefox. Những đoạn kiểm tra domain được compile trực tiếp vào browser engine.

The source code is right there if you want to inspect it yourself.


about:compat của Firefox

Nếu mở Firefox và nhập about:compat trên thanh địa chỉ, bạn sẽ thấy danh sách các intervention dành riêng cho từng website kèm công tắc bật/tắt. Chỉ cần disable chúng là một số website có thể hỏng ngay lập tức.

Hệ thống WebCompat của Firefox có thể:

  • inject CSS và JavaScript riêng cho từng domain,
  • override User-Agent với các website nhận diện browser sai,
  • vá các lỗi compatibility khiến website trông như bị hỏng.

Những intervention này thường được theo dõi trong Bugzilla của Mozilla, kèm bug report và đôi khi cả lịch sử liên hệ không thành công với phía website.

Nói cách khác: thay vì chờ website sửa code, browser thường tự xử lý luôn.


“Quirks” của Safari

Engine WebKit của Safari gọi các workaround kiểu này là “quirks”. File Quirks.cpp trong WebKit chứa hàng nghìn dòng logic riêng theo domain.

Một comment trong source code ghi rằng:

Facebook, X (twitter), and Reddit will naively pause a <video> element that has scrolled out of the viewport, regardless of whether that element is currently in PiP mode.

Vì vậy browser phải nhận diện các domain đó rồi thay đổi cách xử lý Picture-in-Picture.

Một comment khác ghi:

FIXME: Remove this quirk if seatguru decides to adjust their site.

Điều đó cho thấy browser engineer từng cố liên hệ để website sửa lỗi, nhưng cuối cùng workaround vẫn phải tồn tại.

Nếu xem commit history, bạn sẽ thấy rất nhiều ví dụ gần đây. Chỉ trong vài tháng qua, WebKit đã thêm patch riêng cho:

  • Zillow vì ảnh floorplan căn giữa sai,
  • TikTok vì hiển thị sai thông báo “please upgrade your browser”,
  • Instagram Reels resize bất thường,
  • lỗi popover của Netflix,
  • Twitch pause PiP khi đổi tab,
  • Amazon Prime Video từ chối phát trên Safari.

Tất cả các workaround này đều được ship tới toàn bộ người dùng.


Chrome Và Quyền Định Nghĩa “Web Hoạt Động”

Điểm quan trọng là các quirks này không chỉ sửa bug website. Trong nhiều trường hợp, chúng tồn tại vì web hiện đại gần như được xây quanh Chrome.

Quy trình thường diễn ra như sau:

  1. Chrome tung ra feature hoặc behavior mới.
  2. Developer dùng ngay vì Chrome chiếm thị phần lớn.
  3. Các browser khác buộc phải:
    • implement behavior tương tự,
    • hoặc viết workaround riêng để website không vỡ.

Đến lúc Safari hay Firefox bắt kịp hoàn toàn, hàng triệu người dùng có thể đã phụ thuộc vào các patch compatibility này.

WebKit thậm chí còn có User-Agent override khiến Safari giả làm Chrome trên một số nền tảng video hoặc streaming.

Firefox cũng thực hiện User-Agent spoofing thông qua compatibility interventions. Mozilla còn giải thích điều này trong wiki của họ.

Điều này tạo thành một vòng lặp:

  • Developer tối ưu cho Chrome trước.
  • Website hoạt động tốt nhất trên Chrome.
  • Browser khác phải thích nghi.
  • Người dùng blame browser thay vì blame website.
  • Nhiều người chuyển sang Chrome hơn.
  • Chrome càng thống trị mạnh hơn.

Những Workaround Này Không Hề Nhỏ

Các fix này không chỉ là thay đổi CSS đơn giản.

Browser có thể thay đổi:

  • scrolling behavior,
  • touch event handling,
  • viewport calculations,
  • image MIME processing,
  • simulated mouse events,
  • zoom handling,
  • storage access,
  • scrollbar rendering,
  • autocorrect behavior.

Ví dụ WebKit có logic riêng cho tính năng zoom ảnh sản phẩm của Amazon.

Một comment trong source code ghi rằng:

When panning on an Amazon product image, we’re either touching on the #magnifierLens element or its previous sibling.

Safari nhận diện khi người dùng tương tác với trang sản phẩm Amazon rồi thay đổi cách touch event được translate sang mouse event để tính năng zoom hoạt động chính xác.

Website assume một behavior mà Safari bình thường không cung cấp, nên browser phải giả lập riêng cho Amazon.


Vì Sao Chrome Không Cần Quirks File Khổng Lồ

Firefox có about:compat. WebKit có Quirks.cpp. Vậy Chrome ở đâu?

Câu trả lời khá đơn giản: phần lớn web hiện nay vốn đã hoạt động theo cách Chrome mong muốn.

Khi Chromium-based browser chiếm hơn 80% thị phần, developer tự nhiên ưu tiên Chrome trước tiên. Nếu website chạy ổn trên Chrome, nhiều team xem như công việc đã hoàn thành.

Khi Safari hoặc Firefox lỗi, các browser nhỏ hơn phải tự thích nghi.

Chrome không còn đơn thuần chạy theo web nữa. Theo nhiều cách, web đang chạy theo Chrome.

Sự bất đối xứng này định hình internet hiện đại.

Khi Chrome đổi behavior:

  • website update theo,
  • browser khác hoặc phải bắt chước,
  • hoặc chấp nhận compatibility issues.

Điều này rất giống thời Internet Explorer trước đây, khi developer chủ yếu build cho IE và phần còn lại của ecosystem phải vật lộn để theo kịp.

Browser thống trị đã đổi, nhưng cơ chế vận hành gần như không thay đổi.


Browser Vendor Thường Chọn Vá Ngay

Thoạt nhìn, bạn có thể thắc mắc vì sao browser vendor không đơn giản yêu cầu website sửa code.

Đôi khi họ có làm vậy. Nhưng xét về thực tế:

  • người dùng blame browser khi site lỗi,
  • vendor không thể chờ vài tháng để bên thứ ba fix,
  • nhiều website không còn đội ngũ maintain rõ ràng,
  • developer gốc có thể đã nghỉ việc từ lâu.

Với browser engineer, thêm một workaround nhỏ thường nhanh và rẻ hơn rất nhiều.

Một WebKit engineer từng viết blog post giải thích cách một quirk cho FlightAware cuối cùng đã được remove sau khi website sửa implementation.

Nhưng trong một khoảng thời gian, Safari user chỉ có trải nghiệm hoạt động bình thường vì browser chứa patch riêng cho flightaware.com.


Website Của Bạn Có Thể Đang Được Browser “Cứu”

Điều thú vị là phần lớn developer không hề biết website của họ đang được browser workaround phía sau.

Không có:

  • console warning,
  • error message,
  • hay thông báo kiểu “browser vừa sửa bug giúp bạn.”

Mọi thứ đều được thiết kế để vô hình.

Nếu bạn chủ yếu test trên Chrome, rủi ro còn cao hơn. Website có thể trông ổn đơn giản vì assumption của bạn khớp với behavior của Chrome.

Các browser khác sau đó phải lựa chọn:

  • hoặc để website lỗi,
  • hoặc thêm domain của bạn vào danh sách compatibility.

Đó là lý do việc test thường xuyên trên Firefox và Safari vẫn cực kỳ quan trọng.


Web Theo Chuẩn Và Web Ngoài Đời Thật

Specification giống như bản đồ. Còn quirks file mới là địa hình thực tế.

Chúng ta từng tin rằng web standard sẽ loại bỏ browser-specific behavior sau thời Internet Explorer. Nhưng thay vì biến mất, các logic đặc thù browser chỉ chuyển vào bên trong browser.

Ngày nay, các browser không thống trị chứa hàng nghìn workaround nhằm duy trì khả năng tương thích với một hệ sinh thái web được tối ưu mạnh cho Chrome.

Một vài website của tôi từng xuất hiện trong những danh sách đó. Website của bạn c


PHIÊN BẢN TIẾNG VIỆT

Trình Duyệt Đang Âm Thầm Vá Website Cho Bạn

Nếu từng nghĩ rằng trình duyệt chỉ đơn giản “hiển thị HTML theo chuẩn”, thực tế phức tạp hơn rất nhiều. Các browser hiện đại chứa vô số đoạn xử lý đặc biệt dành riêng cho từng website cụ thể.

Những điều kiện này thường có dạng:

  • “Nếu người dùng đang ở domain này thì render khác đi.”
  • “Nếu API kia được gọi trên site nọ thì đổi behavior.”
  • “Nếu video thuộc nền tảng kia thì đừng pause như mặc định.”

Đây không phải lỗi phát sinh ngoài ý muốn. Nó là một phần của cách web hiện đại vận hành, được ship tới hàng tỷ thiết bị trên toàn cầu.

Source code của các cơ chế này hoàn toàn công khai. Bạn có thể tìm thấy chúng trong WebKit hoặc hệ thống tương thích của Firefox. Các điều kiện kiểm tra domain được compile trực tiếp vào browser engine.


about:compat của Firefox

Trong Firefox, nếu mở about:compat, bạn sẽ thấy danh sách các intervention dành riêng cho từng website, kèm công tắc bật/tắt độc lập. Chỉ cần disable chúng là nhiều trang sẽ bắt đầu lỗi ngay lập tức.

Hệ thống WebCompat của Firefox có thể:

  • inject CSS và JavaScript riêng cho từng domain,
  • override User-Agent với các website nhận diện browser sai,
  • vá các lỗi khiến web trông như bị hỏng.

Những intervention này thường được theo dõi trong Bugzilla của Mozilla, kèm bug report và đôi khi cả lịch sử liên hệ không thành công với đội ngũ website.

Nói cách khác: thay vì chờ website sửa code, browser thường tự sửa luôn.


“Quirks” của Safari

Engine WebKit của Safari gọi các workaround kiểu này là “quirks”. File Quirks.cpp trong WebKit chứa hàng nghìn dòng xử lý đặc biệt theo domain.

Một comment trong source code ghi rằng:

Facebook, X và Reddit pause video quá mạnh tay khi video rời viewport, kể cả lúc đang ở chế độ Picture-in-Picture.

Vì thế browser phải nhận diện các domain này rồi thay đổi cách xử lý PiP.

Một comment khác lại ghi:

FIXME: Remove this quirk if SeatGuru fixes their site.

Điều đó cho thấy browser engineer từng cố liên hệ để website sửa lỗi, nhưng cuối cùng workaround vẫn phải tồn tại.

Chỉ trong vài tháng gần đây, WebKit đã thêm các patch riêng cho:

  • lỗi căn giữa ảnh của Zillow,
  • cảnh báo “upgrade your browser” sai của TikTok,
  • Instagram Reels resize bất thường,
  • lỗi popover của Netflix,
  • Twitch pause PiP khi đổi tab,
  • Amazon Prime Video từ chối phát trên Safari.

Tất cả các workaround này đều được ship tới toàn bộ người dùng.


Chrome Và Quyền Định Nghĩa “Web Hoạt Động”

Điểm quan trọng là các quirks này không chỉ sửa bug website. Trong nhiều trường hợp, chúng tồn tại vì web hiện đại gần như được xây quanh Chrome.

Quy trình thường diễn ra như sau:

  1. Chrome giới thiệu feature hoặc behavior mới.
  2. Developer dùng ngay vì Chrome chiếm thị phần lớn.
  3. Các browser khác buộc phải:
    • implement behavior tương tự,
    • hoặc viết workaround riêng để website không vỡ.

Đến lúc Safari hay Firefox bắt kịp hoàn toàn, hàng triệu người dùng có thể đã phụ thuộc vào các patch tương thích này.

WebKit thậm chí còn có User-Agent override khiến Safari giả làm Chrome trên một số nền tảng streaming hoặc video.

Firefox cũng thực hiện User-Agent spoofing thông qua WebCompat.

Điều này tạo thành một vòng lặp:

  • Developer tối ưu cho Chrome trước.
  • Website hoạt động tốt nhất trên Chrome.
  • Browser khác phải thích nghi.
  • Người dùng blame browser thay vì blame website.
  • Nhiều người chuyển sang Chrome hơn.
  • Chrome càng thống trị mạnh hơn.

Những Workaround Này Không Hề Nhỏ

Các fix này không chỉ là vài thay đổi CSS đơn giản.

Browser có thể thay đổi:

  • scrolling behavior,
  • touch event handling,
  • viewport calculations,
  • image MIME handling,
  • simulated mouse events,
  • zoom behavior,
  • storage access,
  • scrollbar rendering,
  • autocorrect behavior.

Ví dụ WebKit có logic riêng cho tính năng zoom ảnh sản phẩm của Amazon.

Safari nhận biết khi người dùng tương tác với trang sản phẩm Amazon rồi thay đổi cách touch event được translate sang mouse event để zoom hoạt động chính xác.

Website assume một behavior mà Safari bình thường không cung cấp, nên browser phải giả lập riêng cho Amazon.


Vì Sao Chrome Không Cần Quirks File Khổng Lồ

Firefox có about:compat. WebKit có Quirks.cpp. Vậy Chrome ở đâu?

Câu trả lời khá đơn giản: phần lớn web hiện nay vốn đã hoạt động theo cách Chrome mong muốn.

Khi Chromium-based browser chiếm phần lớn thị phần, developer tự nhiên ưu tiên Chrome trước tiên. Nếu site chạy ổn trên Chrome, nhiều team xem như công việc đã hoàn thành.

Khi Safari hoặc Firefox lỗi, các browser nhỏ hơn phải tự thích nghi.

Chrome không còn đơn thuần chạy theo web nữa. Theo nhiều cách, web đang chạy theo Chrome.

Sự bất đối xứng này định hình internet hiện đại.

Khi Chrome đổi behavior:

  • website update theo,
  • browser khác hoặc phải bắt chước,
  • hoặc chấp nhận rủi ro compatibility issues.

Điều này rất giống thời Internet Explorer trước đây, khi developer chủ yếu build cho IE và phần còn lại của ecosystem phải vật lộn để bắt kịp.

Browser thống trị đã đổi, nhưng cơ chế vận hành gần như không thay đổi.


Browser Vendor Thường Chọn Vá Ngay

Thoạt nhìn, bạn có thể thắc mắc vì sao browser vendor không đơn giản yêu cầu website sửa code.

Đôi khi họ có làm vậy. Nhưng xét về thực tế:

  • người dùng sẽ blame browser khi site lỗi,
  • vendor không thể chờ vài tháng để bên thứ ba fix,
  • nhiều website không còn đội ngũ maintain rõ ràng,
  • developer gốc có thể đã nghỉ việc từ lâu.

Với browser engineer, thêm một workaround vài dòng thường rẻ và nhanh hơn rất nhiều.

WebKit từng viết quirk riêng cho FlightAware sau khi một thay đổi standards-compliant khiến website xử lý transform matrix sai.

Sau này website đã sửa implementation và quirk bị remove.

Nhưng trong một khoảng thời gian, Safari user chỉ có trải nghiệm hoạt động bình thường vì browser chứa patch riêng cho flightaware.com.


Website Của Bạn Có Thể Đang Được Browser “Cứu”

Điều thú vị là phần lớn developer không hề biết website của họ đang được browser workaround phía sau.

Không có:

  • console warning,
  • error message,
  • hay thông báo kiểu “browser vừa sửa bug giúp bạn.”

Mọi thứ đều được thiết kế để vô hình.

Nếu bạn chủ yếu test trên Chrome, rủi ro còn cao hơn. Website có thể trông ổn đơn giản vì assumption của bạn khớp với behavior của Chrome.

Các browser khác sau đó phải lựa chọn:

  • hoặc để website lỗi,
  • hoặc thêm domain của bạn vào danh sách compatibility.

Đó là lý do việc test thường xuyên trên Firefox và Safari vẫn cực kỳ quan trọng.


Web Theo Chuẩn Và Web Ngoài Đời Thật

Specification giống như bản đồ. Còn quirks file mới là địa hình thực tế.

Chúng ta từng tin rằng web standard sẽ loại bỏ browser-specific behavior sau thời Internet Explorer. Nhưng thay vì biến mất, các logic đặc thù browser chỉ chuyển vào bên trong browser.

Ngày nay, các browser không thống trị chứa hàng nghìn workaround nhằm duy trì khả năng tương thích với một hệ sinh thái web được tối ưu mạnh cho Chrome.

Một vài website của tôi từng xuất hiện trong những danh sách đó. Website của bạn cũng có thể đã nằm trong đó.

Và danh sách ấy vẫn đang tiếp tục dài thêm.