- Safari และ Firefox เผยแพร่โค้ดที่เปลี่ยนการเรนเดอร์และการทำงานของ API บน โดเมนบางแห่ง เช่น TikTok, Netflix และ Instagram
- about:compat ของ Firefox แสดงการแทรกแซงรายเว็บไซต์และสวิตช์เปิดปิด พร้อมทั้งทำการฉีด CSS·JavaScript แบบกำหนดเองและปลอมแปลง user agent
- WebKit ของ Safari จัดการสิ่งนี้ในรูปแบบ quirks และเลี่ยงปัญหาเรื่องวิดีโอ PiP·การจัดแนวภาพ·popover·การเข้าถึงสตรีมมิงตามแต่ละโดเมน
- Chrome แทบไม่ต้องมีไฟล์ข้อยกเว้นแยกต่างหาก เพราะเว็บถูกสร้างโดยยึด Chrome เป็นศูนย์กลาง อยู่แล้ว ทำให้เบราว์เซอร์อื่นต้องมาคอยชดเชยความต่าง
- ข้อยกเว้นเหล่านี้มักไม่ปรากฏชัดในล็อกหรือคอนโซล ดังนั้นนักพัฒนาควรทดสอบบน Firefox และ Safari อย่างสม่ำเสมอ และตรวจสอบว่ามีการใส่ ไฟล์ quirks สำหรับเว็บไซต์ของตนหรือไม่
การจัดการข้อยกเว้นรายโดเมนภายในเบราว์เซอร์
- Safari และ Firefox เผยแพร่โค้ดที่เปลี่ยนการเรนเดอร์หรือการทำงานของ API ตาม โดเมน ที่ผู้ใช้เข้าชม
- เว็บไซต์อย่าง TikTok, Netflix, Instagram และ SeatGuru เป็นเป้าหมายของการ จัดการเฉพาะรายเว็บไซต์ แบบนี้
- สามารถตรวจสอบซอร์สที่เกี่ยวข้องได้แบบสาธารณะใน
Quirks.cpp ของ WebKit และ WebCompat interventions ของ Firefox
- โค้ดเหล่านี้ฝังอยู่ในเอนจินเรนเดอร์ของเบราว์เซอร์ในลักษณะ “ถ้าเป็นโดเมนนี้ให้เรนเดอร์ต่างออกไป” หรือ “ถ้าเป็นโดเมนนี้ให้จัดการการเรียก API ต่างออกไป”
- Chrome แทบไม่จำเป็นต้องมีไฟล์ข้อยกเว้นในแบบเดียวกัน ซึ่งสะท้อนความไม่สมมาตรที่เว็บถูกสร้างโดยมี Chrome เป็นศูนย์กลางอยู่แล้ว
about:compat ของ Firefox
- ถ้าพิมพ์
about:compat ในแถบที่อยู่ของ Firefox จะเห็นรายการ การแทรกแซงรายเว็บไซต์ และสวิตช์เปิดปิด
- แต่ละรายการคือการแก้ไขแบบกำหนดเองสำหรับเว็บไซต์หนึ่ง ๆ และเมื่อปิดลงก็จะเห็นได้ว่าเว็บไซต์พังอย่างไร
- ระบบ WebCompat ของ Firefox ทำการฉีด CSS และ JavaScript แบบกำหนดเองตามโดเมนที่เจาะจง
- สำหรับเว็บไซต์ที่ตรวจจับเบราว์เซอร์ผิด จะมีการส่ง สตริง user agent ที่ถูกเปลี่ยนแปลงไป
- การแทรกแซงเหล่านี้ช่วยปิดบังบั๊กไม่ให้เว็บดูเหมือนเสียหาย และใน Mozilla Bugzilla ก็มีการติดตามทั้งบั๊กรายงานและความพยายามติดต่อเว็บไซต์นั้น ๆ
quirks ของ Safari
- เอนจิน WebKit ของ Safari เรียกการจัดการแบบนี้ว่า quirks และมีการเปิดเผย
Quirks.cpp ไว้บน GitHub
- ในโค้ด WebKit มีคอมเมนต์ว่าบน Facebook, X และ Reddit จะมีการพัก
<video> ที่ถูกเลื่อนออกนอกจอ ไม่ว่าจะอยู่ในโหมด PiP หรือไม่ก็ตาม
- Safari ตรวจจับ
facebook.com, x.com, reddit.com แล้วเปลี่ยนวิธีจัดการวิดีโอแบบ Picture-in-Picture
- แม้โค้ดวิดีโอของเว็บไซต์จะพัง เบราว์เซอร์ก็ไม่รอให้บริษัทเหล่านั้นแก้เอง แต่เผยแพร่ทางแก้แบบอ้อมให้ผู้ใช้ทุกคนทันที
- ในคอมเมนต์ที่เกี่ยวกับ SeatGuru มีข้อความว่า
FIXME: Remove this quirk if seatguru decides to adjust their site. ซึ่งแสดงให้เห็นว่าหากเว็บไซต์แก้ไขแล้ว ก็สามารถลบข้อยกเว้นนี้ออกได้
- ในประวัติคอมมิต มีการเพิ่มการแก้ไขรายเว็บไซต์หลายรายการในช่วงไม่กี่เดือนที่ผ่านมา
- ปัญหาที่ ภาพ floorplan ของ Zillow ไม่จัดกึ่งกลาง
- ปัญหาที่ TikTok แสดงข้อความ “please upgrade your browser”
- ปัญหาที่ Instagram Reels ปรับขนาดแบบไม่สม่ำเสมอระหว่างเล่น
- ปัญหาที่ปุ่ม “Episodes and Info” ของ Netflix ปิด popover ผิดพลาด
- ปัญหาที่ Twitch พักวิดีโอ PiP เมื่อสลับแท็บ
- ปัญหาที่ Amazon Prime Video ไม่ยอมให้ผู้ใช้ Safari รับชม
เว็บที่มี Chrome เป็นศูนย์กลางและความไม่สมมาตร
- quirks ของ WebKit และ WebCompat ของ Firefox ไม่ได้แค่ซ่อมเว็บไซต์ที่พัง แต่ยังชดเชยสถานการณ์ที่ Chrome เป็นตัวกำหนดนิยามของคำว่า “ใช้งานได้” ด้วย
- โดยทั่วไปเมื่อ Chrome ปล่อยฟีเจอร์ออกมา ด้วยอำนาจเหนือตลาด นักพัฒนาก็จะใช้ฟีเจอร์นั้น แล้วเบราว์เซอร์อื่นต้องไปทำฟีเจอร์ตามหรือไม่ก็ใช้ ข้อยกเว้นรายเว็บไซต์ เพื่อปิดช่องว่าง
- กว่า Safari และ Firefox จะตามทัน การจัดการข้อยกเว้นก็มักถูกปล่อยไปถึงผู้ใช้หลายล้านคนแล้ว
- ใน WebKit มี การ override user agent ที่ทำให้ Safari ดูเหมือนเป็น Chrome บนหน้าวิดีโอของ Amazon และบริการสตรีมมิงอีกหลายแห่ง
- เว็บไซต์เหล่านี้ตรวจจับว่าเป็น Chrome หรือไม่แล้วมอบประสบการณ์ที่ด้อยกว่าสำหรับเบราว์เซอร์อื่น ดังนั้น WebKit จึงต้องปลอมตัวตนของเบราว์เซอร์เพื่อปกป้องผู้ใช้ Safari
- ปัจจุบันใน
Quirks.cpp มีสตริง user agent ของ Chrome ปลอมดังนี้
auto chromeUserAgent = "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36"_s;
- Firefox ก็ทำงานในลักษณะเดียวกัน และการแทรกแซงจำนวนมากใน
about:compat ก็คือการปลอม user agent เพื่อบอกเว็บไซต์ว่า “ฉันคือ Chrome”
- Mozilla wiki ระบุว่า บางเว็บไซต์ “บล็อกการเข้าถึงโดยสิ้นเชิง แสดงดีไซน์คนละแบบ หรือให้ฟังก์ชันคนละอย่าง” ตามผลลัพธ์ของการตรวจจับเบราว์เซอร์
- โครงสร้างนี้ก่อให้เกิดวงจรป้อนกลับ
- นักพัฒนาสร้างเว็บโดยยึด Chrome เป็นหลัก เพราะ Chrome มีส่วนแบ่งสูง
- เว็บไซต์จึงทำงานได้ดีที่สุดบน Chrome
- ผู้ใช้ที่พบบั๊กบนเบราว์เซอร์อื่นจะโทษเบราว์เซอร์ ไม่ใช่เว็บไซต์
- ผู้ใช้ย้ายไป Chrome และอำนาจนำของ Chrome ก็ยิ่งแข็งแรงขึ้น
- เหตุผลที่ Chrome แทบไม่ต้องมีไฟล์ quirks แยก ไม่ใช่เพราะ Chrome ออกแบบมาดีกว่า แต่เพราะเว็บถูกปรับให้เข้ากับ Chrome อยู่แล้ว
- ในสถานการณ์ที่ผู้ใช้เบราว์เซอร์บนฐาน Chromium มีสัดส่วนเกิน 80% นักพัฒนาจึงมุ่งเป้า Chrome ก่อน
- ถ้าเว็บไซต์ทำงานบน Chrome ได้ก็พร้อมปล่อยใช้งาน และถ้าแตกบน Safari หรือ Firefox ปัญหานั้นก็มักถูกลดลำดับความสำคัญ
- Chrome ไม่ได้เพิ่มข้อยกเว้นมากเท่ากับทำหน้าที่ กำหนดวาระ
- เมื่อ Chrome เปลี่ยนพฤติกรรมบางอย่าง เว็บไซต์ก็จะอัปเดตตามนั้น ส่วนเบราว์เซอร์อื่นต้องตามให้ทันหรือไม่ก็พัง
ช่องว่างระหว่างสเปกกับเว็บจริง
- วิศวกรเบราว์เซอร์อาจมองว่าปัจจุบันสเปกถูกกำหนดไว้ค่อนข้างดี และแนวทาง “living specification” ของ HTML5 ก็ช่วยลดความวุ่นวายในยุค IE/Netscape ได้
- ปัญหาคือ นักพัฒนาพึ่งพา รายละเอียดการติดตั้งใช้งาน ที่ไม่ได้อยู่ในสเปก และเมื่อรายละเอียดเหล่านั้นต่างกันในเบราว์เซอร์อื่น ก็กลับโทษว่าเบราว์เซอร์นั้นไม่สอดคล้อง
- หากการติดตั้งใช้งานของ Chrome กลายเป็นมาตรฐานอ้างอิงของทุกคน พฤติกรรมรายละเอียดนอกสเปกของ Chrome ก็จะกลายเป็นสเปกโดยพฤตินัย
- ในยุค Internet Explorer ช่วงทศวรรษ 2000 นักพัฒนาก็สร้างเว็บไซต์ให้เข้ากับ IE ทำให้เว็บพังบนเบราว์เซอร์อื่น และการ “ทำงานบน IE ได้” มีความสำคัญเหนือการทำตามมาตรฐาน
- ในอดีตเคยคาดหวังว่าถ้าเว็บยึดมาตรฐานมากขึ้น quirks ของเบราว์เซอร์จะหายไป แต่ความจริงคือ quirks ไม่ได้หายไป เพียงย้ายไปอยู่ในเบราว์เซอร์ที่ไม่ใช่ Chrome
- มาตรฐานถูกสร้างขึ้นมาเพื่อกำจัดโค้ดเฉพาะเบราว์เซอร์ แต่หลังจากพ้นยุค IE ไปแล้ว ช่องโหว่แบบเดิมก็กลับมาอีกในรูปแบบที่ยึดเบราว์เซอร์อื่นเป็นศูนย์กลาง
- ตอนนี้โค้ดเฉพาะเบราว์เซอร์ไม่ได้อยู่ในเบราว์เซอร์เจ้าตลาด แต่กลับไปอยู่ใน เบราว์เซอร์ที่ไม่ใช่เจ้าตลาด เพื่อชดเชยเว็บที่ถูกปรับมาเพื่อเบราว์เซอร์เจ้าตลาด
การจัดการข้อยกเว้นลึกกว่าที่คิด
- การจัดการแบบนี้ไม่ได้จำกัดอยู่แค่การปรับหน้าตา แต่เปลี่ยน พฤติกรรมพื้นฐาน ของเบราว์เซอร์ตามโดเมนด้วย
- เฉพาะรายการของ WebKit ก็ยาวนับพันบรรทัดแล้ว ครอบคลุมตั้งแต่พฤติกรรมการเลื่อน การจัดการ touch event การคำนวณ viewport ไปจนถึงการจัดการ MIME type ของภาพ
- ในคอมเมนต์เกี่ยวกับฟังก์ชันซูมภาพสินค้า Amazon มีข้อความดังนี้
When panning on an Amazon product image, we’re either touching on the #magnifierLens element or its previous sibling.
- Safari ตรวจสอบก่อนว่าเข้าถึง Amazon อยู่หรือไม่ แล้วจึงเปลี่ยนวิธีแปลง touch event เป็น mouse event เพื่อให้ฟังก์ชันซูมสินค้าใช้งานได้
- เนื่องจากเว็บไซต์ Amazon สมมติพฤติกรรม event บางอย่างที่ต่างจากพฤติกรรมปกติของ Safari Safari จึงมอบพฤติกรรมนั้นให้เฉพาะกับ Amazon เท่านั้น
- ยังมี quirks แบบรายโดเมนสำหรับ storage access, การเรนเดอร์ scrollbar, พฤติกรรม autocorrect และการจัดการการซูมเข้าออกด้วย
- ข้อยกเว้นแต่ละอย่างถูกวางไว้หลังการตรวจสอบโดเมน และถูกคอมไพล์อยู่ภายในตัว executable ของเบราว์เซอร์
ทำไมเบราว์เซอร์ถึงแก้เองแทนที่จะรอ
- บางครั้งผู้ผลิตเบราว์เซอร์ก็พยายามติดต่อเว็บไซต์ที่มีปัญหาเพื่อขอให้แก้ไข และในซอร์สโค้ดก็มีฟิลด์ที่ลิงก์ไปยังความพยายามด้าน outreach ด้วย
- แต่ถ้าเว็บไซต์ยอดนิยมทำงานได้บน Chrome แต่พังบนเบราว์เซอร์ของตน ผู้ใช้จะโทษเบราว์เซอร์ ไม่ใช่เว็บไซต์
- สำหรับฝั่งเบราว์เซอร์ การปล่อยทางแก้แบบอ้อม 5 บรรทัดในวันถัดไปนั้นใช้งานได้จริงกว่าการส่งบั๊กให้บุคคลภายนอกแล้วรอเป็นสัปดาห์หรือเป็นเดือน
- แม้แต่การจะติดต่อใครก็อาจไม่ชัดเจน
- นักพัฒนาที่เขียนโค้ดที่พังอาจลาออกจากบริษัทไปแล้ว
- ทีมที่เป็นเจ้าของ endpoint นั้นอาจไม่ตระหนักว่าตนต้องรับผิดชอบ
- เว็บไซต์นั้นอาจอยู่ในโหมดบำรุงรักษาที่รับแค่แพตช์ความปลอดภัย
- สำหรับเบราว์เซอร์ ทางเลือกที่ง่ายกว่าคือแก้ให้ทันทีแบบมองไม่เห็น เพื่อลดปัญหาของผู้ใช้
- มีบทความของวิศวกร WebKit ที่พูดถึงกระบวนการลบ quirk ของ FlightAware ด้วย
- FlightAware เปรียบเทียบสตริง CSS transform matrix และเมื่อสเปก CSS เปลี่ยนวิธี serialize ค่า พอเบราว์เซอร์ทำตามสเปก เว็บไซต์ก็พัง
- วิศวกรจึงเพิ่มโค้ดรายโดเมนที่ตรวจ
flightaware.com และต่อมาหลังจากติดต่อสำเร็จ FlightAware ก็แก้โค้ด ทำให้ quirk ถูกลบออก
- ตลอดหลายเดือนนั้น ผู้ใช้ Safari ยังคงได้รับประสบการณ์ที่ใช้งานได้ปกติด้วย
if ภายในเบราว์เซอร์
สิ่งที่นักพัฒนาควรตรวจสอบ
- เว็บไซต์ของคุณอาจกำลังได้รับ การจัดการเรนเดอร์แบบพิเศษ โดยที่คุณไม่รู้ตัว
- quirk เหล่านี้จะไม่ปรากฏใน error log และคอนโซลก็จะไม่เตือนว่า “เบราว์เซอร์กำลังเลี่ยงความผิดพลาดอยู่”
- การแก้แบบอ้อมถูกออกแบบมาให้ทำงานอย่างมองไม่เห็นโดยเจตนา
- เว็บไซต์ที่ทดสอบโดยยึด Chrome เป็นหลักมีความเสี่ยงเป็นพิเศษ
- เหตุผลที่เว็บไซต์ดูเหมือนทำงานได้สมบูรณ์ อาจไม่ใช่เพราะโค้ดดี แต่เพราะพฤติกรรมของ Chrome ดันตรงกับสมมติฐานของนักพัฒนา
- เบราว์เซอร์อื่นจึงต้องเลือกระหว่างแสดงเว็บไซต์ที่พังให้ผู้ใช้เห็น หรือเพิ่มเข้าไปในไฟล์ quirks
- คุณควรเปิดเว็บไซต์บน Firefox และ Safari เป็นประจำ ไม่ใช่แค่นาน ๆ ครั้ง
- ไฟล์ quirks มีอยู่ก็เพราะนักพัฒนาไม่ได้ทำแบบนั้นอย่างสม่ำเสมอ
- ถ้าโดเมนของคุณอยู่ในไฟล์ quirks คุณก็ควรตรวจสอบว่ามีส่วนใดที่เบราว์เซอร์ต้องคอยแก้แบบอ้อมให้
- เว็บยังคงทำงานต่อไปได้แม้ไม่มีการแทรกแซงจากนักพัฒนา แต่ก็อาจเป็นเพราะวิศวกรของเบราว์เซอร์ที่คุณไม่ได้ใช้งานกำลังแก้ปัญหาที่คุณไม่เคยรู้มาก่อนแทนอยู่
1 ความคิดเห็น
ความคิดเห็นจาก Lobste.rs
มีประเด็นน่าสนใจซ่อนอยู่หลัง บทพร่ำเพ้อเรื่อง LLM
คุณอาจไม่ชอบสไตล์การเขียนก็ได้ และผมก็ไม่ได้อยากเถียงเรื่องนั้น แต่บทความที่เขียนไม่ดีก็ไม่ได้แปลว่าต้องเขียนโดย AI เสมอไป ก่อนยุค AI ก็มีประโยคแย่ ๆ มากมายอยู่แล้ว
มันน่าเสียดาย และผมอยากอยู่ในโลกที่ Google ไม่ได้มีอิทธิพลต่อเว็บมากขนาดนี้ ความฝันของ “เว็บ” เคยทะเยอทะยานกว่านี้มาก และสำหรับผมแล้วก็เคยสร้างแรงบันดาลใจได้มากกว่านี้ เลยยิ่งน่าเสียดายที่มันกลายมาเป็นแบบทุกวันนี้
บล็อกคำพูดอ่านยาก อาจจะเป็นปัญหาของ โหมดมืด ก็ได้
แต่รายละเอียดที่แชร์เกี่ยวกับวิธีเลี่ยงปัญหาก็มีประโยชน์
ช่วงที่บอกว่า “เว็บไซต์พวกนี้ตรวจจับว่าเป็น Chrome หรือไม่ แล้วมอบประสบการณ์ที่ด้อยกว่าให้เบราว์เซอร์อื่น ดังนั้นแทนที่จะปล่อยให้ผู้ใช้ Safari ลำบาก WebKit ก็เลยโกหกว่าเป็นเบราว์เซอร์อื่น” ดูเป็นเรื่องที่เกิดซ้ำ ๆ ทั่วทั้งวงการนี้
แม้แต่ผู้ผลิตคอมพิวเตอร์ก็ออก เฟิร์มแวร์ ACPI ที่ซ่อนข้อมูลจากระบบปฏิบัติการที่ไม่รองรับอยู่บ่อย ๆ สุดท้ายระบบปฏิบัติการเหล่านั้นก็ต้องแกล้งทำเป็น Windows เพื่อหลอกเฟิร์มแวร์กลับ
ผมไม่ชอบที่บทความนี้อ่านแล้วให้อารมณ์เหมือน สำนวนแบบ AI
นอกจากที่พูดไว้แล้ว ยังมี วงจรป้อนกลับอยู่สองแบบ อีกด้วย แบบแรกคือ Chrome ครองตลาดจนทำให้นักพัฒนาสร้างเว็บโดยยึด Chrome เป็นหลัก ผลคือมันทำงานดีที่สุดบน Chrome แล้วพอมีปัญหาบนเบราว์เซอร์อื่น ผู้ใช้ก็โทษเบราว์เซอร์แทนที่จะโทษเว็บไซต์ แล้วก็ย้ายไปใช้ Chrome
อีกแบบคือเว็บไซต์พังบน Firefox แต่เจ้าของเว็บไซต์กลับบอกว่าในสถิติไม่เห็นมีผู้ใช้ Firefox เลย เรื่องแบบนี้เกิดได้แม้จะมีการจัดการแบบพิเศษอย่างเปลี่ยน user agent
ถ้าจำไม่ผิด Opera รุ่นคลาสสิก (Presto) เป็นตัวแรกที่เริ่มทำชั้นความเข้ากันได้แบบนี้
การที่ implementation กลายเป็น specification เป็นปัญหาที่แพร่หลายมากในวงการนี้ ที่ทำงานเก่าของผมเคยใช้ภาษาเวิร์กโฟลว์ที่มีการทดสอบความสอดคล้อง โดยหวังว่าจะมีหลาย implementation เกิดขึ้นและทำให้เวิร์กโฟลว์พกพาข้ามระบบได้
ปัญหาหลักคือแรงจูงใจทางเศรษฐกิจในการทำให้พกพาได้อย่างสมบูรณ์นั้นต่ำมาก คนทำย่อมอยากใส่ความสามารถเสริมใน implementation ของตัวเองเพื่อให้คนอยู่กับผลิตภัณฑ์นั้นต่อไป
อีกอย่างคือไม่มีเวลาไปสร้างซอฟต์แวร์กันแบบคณะกรรมการ เลยอยากรีบทำฟีเจอร์ใหม่ใส่เข้าไปก่อน
implementation กลายเป็น specification ก็เพราะเราอยู่ในสังคมมนุษย์
ไม่ใช่เรื่องใหม่เลย เบราว์เซอร์ส่วนน้อยมักมีแฮ็กสำหรับบางเว็บไซต์อยู่เสมอ และเมื่อก่อนเป้าหมายก็คือ IE ทางเลือกเดียวคือปล่อยให้เว็บพังต่อไป
เมื่อหลายสิบปีก่อน นักพัฒนาเว็บทำเว็บที่ใช้ได้เฉพาะบน IE แล้วก็บอกว่า “ถ้าจะใช้เว็บนี้ก็ไปใช้ IE” ตอนนี้เรื่องเดียวกันแค่เกิดซ้ำกับ Chrome จะบอกว่า Chrome ถูกหรือผิดก็ไม่สำคัญ เว็บไซต์มันใช้ได้แค่บน Chrome และถ้าเบราว์เซอร์อื่นไม่รับประกันพฤติกรรมแบบ Chrome บนเว็บนั้น คนก็จะบอกว่า “เบราว์เซอร์นี้พัง” แล้วก็ย้ายไป Chrome
ผมสงสัยจริง ๆ ว่าคนคิดกันหรือเปล่าว่า Gecko กับ WebKit ควรปล่อยให้เว็บไซต์เหล่านี้พังอยู่แบบนั้นเพราะยึดหลักการ หรือคิดว่าทุกคนควรใช้แต่ Chrome และไม่ควรใช้เบราว์เซอร์อื่น เพราะทางเลือกแทนแฮ็กเฉพาะเว็บไซต์ก็มีแค่สองอย่างนั้น
ผมว่ามันน่าขำที่ Firefox กับ Safari แกล้งทำเป็น Chrome ผ่าน user agent
แต่ใน user agent string ของ Chrome เองก็ยังมีซากดึกดำบรรพ์จากยุคที่มันแกล้งทำเป็นเบราว์เซอร์ Mozilla และแกล้งทำเป็นเบราว์เซอร์ของ Apple อยู่
มีชั้นตะกอนทางธรณีวิทยาสะสมอยู่ในโค้ดบรรทัดนี้: