4 poin oleh GN⁺ 3 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Safari dan Firefox merilis kode yang mengubah rendering dan perilaku API pada domain tertentu seperti TikTok, Netflix, dan Instagram
  • about:compat di Firefox menampilkan intervensi per situs dan tombol toggle, serta melakukan injeksi CSS·JavaScript khusus dan penyamaran user agent
  • WebKit di Safari mengelola ini sebagai quirks, dan membuat solusi per domain untuk masalah akses video PiP, perataan gambar, popover, dan streaming
  • Chrome hampir tidak memerlukan file pengecualian terpisah karena web sudah dibangun dengan berpusat pada Chrome, sehingga browser lain yang harus menyesuaikan perbedaannya
  • Karena pengecualian seperti ini tidak terlihat jelas di log atau konsol, developer perlu rutin menguji di Firefox dan Safari serta memeriksa apakah file quirks mereka terlibat

Penanganan pengecualian per domain di dalam browser

  • Safari dan Firefox merilis kode yang mengubah rendering atau perilaku API tergantung pada domain yang dikunjungi pengguna
  • Situs seperti TikTok, Netflix, Instagram, dan SeatGuru menjadi target penanganan per situs seperti ini
  • Sumber terkait dapat dilihat secara publik di Quirks.cpp milik WebKit dan WebCompat interventions milik Firefox
  • Kode ini dimasukkan ke dalam engine rendering browser dengan cara seperti “render berbeda jika domain tertentu” atau “tangani pemanggilan API secara berbeda jika domain tertentu”
  • Chrome pada praktiknya tidak memerlukan file pengecualian seperti ini, yang memperlihatkan asimetri bahwa web sudah dibuat dengan berpusat pada Chrome

about:compat di Firefox

  • Jika memasukkan about:compat di bilah alamat Firefox, Anda dapat melihat daftar intervensi per situs dan tombol toggle
  • Setiap item adalah perbaikan khusus untuk situs web tertentu, dan jika dimatikan Anda bisa melihat situs tersebut menjadi rusak
  • Sistem WebCompat milik Firefox menyuntikkan CSS dan JavaScript khusus untuk domain tertentu
  • Untuk situs yang salah mendeteksi browser, Firefox mengirimkan string user agent yang telah diubah
  • Intervensi ini menutupi bug agar web tidak tampak rusak, dan di Mozilla Bugzilla bahkan dilacak laporan bug serta upaya menghubungi situs terkait

quirks di Safari

  • Engine WebKit di Safari menyebut penanganan seperti ini sebagai quirks, dan Quirks.cpp dibuka secara publik di GitHub
  • Di kode WebKit ada komentar bahwa Facebook, X, dan Reddit menjeda <video> yang di-scroll keluar layar terlepas dari apakah mode PiP aktif atau tidak
  • Safari mendeteksi facebook.com, x.com, dan reddit.com, lalu mengubah penanganan video Picture-in-Picture
  • Meski kode video situsnya rusak, browser tidak menunggu perusahaan-perusahaan itu memperbaikinya, melainkan langsung merilis solusi untuk semua pengguna
  • Komentar terkait SeatGuru berbunyi FIXME: Remove this quirk if seatguru decides to adjust their site., yang menunjukkan bahwa pengecualian bisa dihapus jika situs tersebut diperbaiki
  • Riwayat commit memperlihatkan berbagai perbaikan spesifik situs dalam beberapa bulan terakhir
    • Masalah gambar floorplan Zillow yang tidak rata tengah
    • Masalah munculnya pesan “please upgrade your browser” di TikTok
    • Masalah Instagram Reels yang ukurannya berubah tidak teratur saat diputar
    • Masalah tombol “Episodes and Info” di Netflix yang menutup popover secara keliru
    • Masalah Twitch yang menjeda video PiP saat berpindah tab
    • Masalah Amazon Prime Video yang tidak mengizinkan pengguna Safari menonton

Web yang berpusat pada Chrome dan asimetri

  • Quirks di WebKit dan WebCompat di Firefox bukan sekadar memperbaiki situs rusak, tetapi juga mengoreksi situasi ketika Chrome menentukan standar praktis dari apa yang dianggap “berfungsi”
  • Umumnya saat Chrome merilis suatu fitur, karena dominasi pasarnya developer akan memakai fitur itu, lalu browser lain harus mengimplementasikannya atau menutupi perbedaannya dengan pengecualian per situs
  • Saat Safari dan Firefox berhasil mengejar, penanganan pengecualian itu sering kali sudah terdistribusi ke jutaan pengguna
  • WebKit menyertakan override user agent yang membuat Safari tampak seperti Chrome pada halaman video Amazon dan berbagai layanan streaming lainnya
  • Situs-situs ini mendeteksi apakah browser adalah Chrome lalu memberikan pengalaman yang diturunkan ke browser lain, sehingga WebKit menyamarkan identitas browser demi melindungi pengguna Safari
  • Saat ini Quirks.cpp memuat string user agent Chrome palsu seperti berikut
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 juga bekerja dengan cara yang sama, dan banyak intervensi di about:compat adalah penyamaran user agent untuk memberi tahu situs bahwa “saya adalah Chrome”
  • Mozilla wiki menjelaskan bahwa beberapa situs “sepenuhnya memblokir akses, menampilkan desain yang berbeda, atau menyediakan fitur yang berbeda” tergantung hasil deteksi browser
  • Struktur ini menciptakan feedback loop
    • Developer membuat dengan acuan Chrome karena pangsa Chrome tinggi
    • Situs bekerja paling baik di Chrome
    • Pengguna yang menemukan bug di browser lain menyalahkan browser, bukan situsnya
    • Pengguna berpindah ke Chrome, dan dominasi Chrome makin menguat
  • Alasan Chrome hampir tidak memerlukan file quirks terpisah bukan karena Chrome dirancang lebih baik, melainkan karena web memang sudah disesuaikan untuk Chrome
  • Dalam situasi ketika pengguna browser berbasis Chromium melebihi 80%, developer cenderung menjadikan Chrome sebagai target utama
  • Jika situs berjalan di Chrome, ia akan dirilis, dan jika rusak di Safari atau Firefox, prioritas masalah itu menjadi rendah
  • Alih-alih menambah pengecualian, Chrome menentukan agenda
  • Saat Chrome mengubah suatu perilaku, situs memperbarui diri mengikuti perubahan itu, dan browser lain harus ikut atau menjadi rusak

Kesenjangan antara spesifikasi dan web nyata

  • Para engineer browser bisa saja menilai bahwa spesifikasi saat ini sudah didefinisikan dengan baik, dan pendekatan “living specification” di HTML5 telah mengurangi kekacauan era IE/Netscape
  • Masalahnya adalah developer bergantung pada detail implementasi yang tidak ada dalam spesifikasi, lalu menyalahkan browser yang dianggap tidak patuh ketika detail itu berbeda di browser lain
  • Jika implementasi Chrome menjadi acuan yang ditargetkan semua orang, maka perilaku detail Chrome di luar spesifikasi berubah menjadi spesifikasi de facto
  • Pada era Internet Explorer di tahun 2000-an, developer juga membuat situs mengikuti IE sehingga situs rusak di browser lain, dan “berfungsi di IE” menjadi lebih penting daripada kepatuhan standar
  • Dulu ada harapan bahwa jika web lebih patuh pada standar maka quirks browser akan hilang, tetapi yang terjadi sebenarnya bukan quirks hilang, melainkan berpindah ke browser non-Chrome
  • Standar dibuat untuk menghilangkan kode spesifik browser, tetapi setelah keluar dari era IE, lubang yang sama kembali terbentuk dengan pusat browser yang berbeda
  • Kini kode spesifik browser tidak lagi berada di browser dominan, melainkan di browser non-dominan yang harus mengoreksi web yang telah disesuaikan dengan browser dominan

Penanganan pengecualian lebih dalam dari yang dibayangkan

  • Penanganan seperti ini bukan sekadar penyesuaian visual sederhana, tetapi mengubah perilaku dasar browser tergantung domain
  • Daftar di WebKit saja mencapai ribuan baris, mencakup perilaku scroll, penanganan touch event, perhitungan viewport, hingga penanganan tipe MIME gambar
  • Komentar untuk fitur zoom gambar produk Amazon memuat isi berikut
When panning on an Amazon product image, we’re either touching on the #magnifierLens element or its previous sibling.
  • Safari memeriksa apakah pengguna membuka Amazon, lalu mengubah cara konversi touch event menjadi mouse event demi fitur pembesaran produk
  • Karena situs Amazon mengasumsikan perilaku event tertentu yang berbeda dari perilaku bawaan Safari, Safari menyediakan perilaku itu hanya untuk Amazon
  • Ada juga quirks per domain untuk storage access, rendering scrollbar, perilaku autocorrect, dan penanganan zoom
  • Setiap pengecualian berada di balik pemeriksaan domain, lalu dikompilasi ke dalam executable browser

Mengapa browser memperbaiki sendiri alih-alih menunggu

  • Terkadang vendor browser menghubungi situs yang bermasalah dan meminta perbaikan, dan dalam source code bahkan ada field yang menautkan upaya outreach
  • Namun jika situs populer berjalan di Chrome tetapi rusak di browser mereka sendiri, pengguna akan menyalahkan browser, bukan situsnya
  • Daripada mengirim bug ke pihak ketiga lalu menunggu beberapa minggu atau bulan, bagi browser lebih praktis merilis solusi lima baris keesokan harinya
  • Bahkan siapa yang harus dihubungi pun bisa jadi tidak jelas
    • Developer yang menulis kode rusak itu mungkin sudah keluar dari perusahaan
    • Tim yang memiliki endpoint terkait mungkin tidak sadar bahwa mereka yang bertanggung jawab
    • Situs tersebut bisa saja berada dalam mode pemeliharaan dan hanya menerima patch keamanan
  • Dari sudut pandang browser, pilihan yang paling sederhana adalah memperbaikinya secara langsung, segera, dan tanpa terlihat untuk mengurangi masalah pengguna
  • Ada juga tulisan dari engineer WebKit yang membahas proses penghapusan quirk FlightAware
  • FlightAware membandingkan string CSS transform matrix, lalu ketika spesifikasi CSS mengubah cara serialisasi nilai dan browser mengikuti spesifikasi itu, situs tersebut menjadi rusak
  • Para engineer menambahkan kode per domain yang memeriksa flightaware.com, lalu setelah upaya kontak berhasil dan FlightAware memperbaiki kodenya, quirk itu dihapus
  • Selama beberapa bulan itu, pengguna Safari tetap mendapatkan pengalaman normal berkat pernyataan if di dalam browser

Hal yang perlu diperiksa developer

  • Bisa jadi situs web Anda menerima penanganan rendering khusus tanpa Anda sadari
  • Quirk seperti ini tidak muncul di log error, dan konsol juga tidak menampilkan peringatan bahwa “browser sedang mengakali kesalahan”
  • Solusi semacam ini memang sengaja dibuat tidak terlihat
  • Situs yang diuji terutama di Chrome sangat berisiko
  • Alasan situs tampak berjalan sempurna mungkin bukan karena kodenya bagus, melainkan karena perilaku Chrome kebetulan sesuai dengan asumsi developer
  • Browser lain harus memilih antara menampilkan situs dalam keadaan rusak kepada pengguna, atau menambahkannya ke file quirks
  • Situs harus dibuka di Firefox dan Safari secara rutin, bukan hanya sesekali
  • File quirks ada justru karena developer tidak melakukan itu secara teratur
  • Jika domain Anda ada di dalam file quirks, Anda perlu memeriksa bagian mana yang sedang diakali oleh browser
  • Web memang tetap berjalan tanpa campur tangan developer, tetapi bisa jadi engineer dari browser yang tidak Anda pakai telah memperbaiki masalah yang tidak pernah Anda ketahui

1 komentar

 
GN⁺ 3 jam lalu
Opini di Lobste.rs
  • Ada cerita menarik yang tersembunyi di balik ocehan LLM

    • Sayangnya tulisannya terlalu buruk sampai-sampai saya tidak bisa menemukan ceritanya. Sebenarnya ini tulisan yang cukup dibaca judulnya saja
    • Orang-orang yang memberi upvote pada komentar ini mungkin sebaiknya melaporkan tulisan ini sebagai spam
    • Cukup menjengkelkan karena nadanya bolak-balik antara menggiring secara sensasional lalu tiba-tiba menjelaskan informasi bypass kompatibilitas browser dengan tenang
    • Kalau mau dibilang sopan, belakangan ini makin banyak komentar yang asal menyimpulkan sesuatu sebagai “ocehan LLM” tanpa dasar. Seolah lupa bahwa LLM terlihat seperti tulisan justru karena dilatih dengan tulisan
      Gaya menulisnya bisa saja tidak disukai, dan saya tidak terlalu ingin berdebat soal itu, tetapi hanya karena tulisannya buruk bukan berarti pasti ditulis AI. Bahkan sebelum AI pun sudah banyak kalimat yang jelek
    • Saya ingin seseorang menjelaskan dengan jelas sebenarnya masalah apa yang dipersoalkan komentar ini beserta thread lanjutannya. Tulisannya mudah dibaca dan informatif, jadi saya tidak paham apa masalahnya
  • Ini menyedihkan, dan saya berharap kita hidup di dunia tempat Google tidak terlalu banyak menentukan arah web seperti ini. Mimpi tentang “web” dulu jauh lebih ambisius dan, bagi saya pribadi, lebih menginspirasi, jadi disayangkan jadinya seperti sekarang

  • Blok kutipannya sulit dibaca. Mungkin ini masalah dark mode
    Namun, membagikan detail solusi workaround itu tetap berguna

    • Betul, kontrasnya nyaris tidak ada. Di mode terang juga tidak terlalu bagus, hanya sedikit lebih baik daripada dark mode. Rasanya seperti pembuat situsnya tidak pernah benar-benar melihat hasilnya sendiri dan cuma ngoding sambil merem
  • Bagian “Situs-situs ini mendeteksi apakah browser-nya Chrome lalu memberi pengalaman yang diturunkan untuk browser lain. Jadi alih-alih membiarkan pengguna Safari kesulitan, WebKit berbohong tentang browser apa dirinya” terasa seperti pola yang berulang di seluruh industri ini
    Produsen komputer juga tidak jarang merilis firmware ACPI yang menyembunyikan informasi dari sistem operasi yang tidak didukung, sehingga pada akhirnya OS tersebut harus berpura-pura menjadi Windows untuk mengakali firmware itu

  • Saya tidak suka karena tulisan ini terasa seperti gaya AI

  • Selain yang disebut di sini, ada dua feedback loop lagi. Yang satu, karena Chrome dominan, developer membuat untuk Chrome, lalu situs paling baik berjalan di Chrome, dan ketika ada masalah di browser lain, pengguna menyalahkan browser-nya, bukan situsnya, lalu pindah ke Chrome
    Yang lain, situs rusak di Firefox tetapi operator situs berkata mereka tidak melihat pengguna Firefox di statistik. Ini bisa tetap terjadi bahkan kalau ada perlakuan khusus seperti mengganti user agent

  • Kalau saya ingat benar, Opera klasik (Presto) adalah yang pertama mulai menerapkan lapisan kompatibilitas seperti ini

  • Implementasi menjadi spesifikasi adalah masalah yang tersebar luas di bidang ini. Di pekerjaan lama, kami memakai bahasa workflow dengan uji kesesuaian sambil berharap akan muncul beberapa implementasi dan workflow-nya menjadi portabel
    Masalah intinya adalah insentif ekonomi untuk membuat portabilitas penuh itu rendah. Orang cenderung ingin menambahkan fitur ekstra ke implementasi mereka sendiri agar pengguna tetap bertahan di produk itu
    Selain itu, tidak ada waktu untuk membuat perangkat lunak ala komite, jadi orang ingin lebih dulu membuat dan memasukkan fitur baru
    Implementasi menjadi spesifikasi karena kita hidup dalam masyarakat manusia

  • Ini bukan hal baru. Browser minoritas selalu punya hack untuk situs tertentu, dan dulu targetnya adalah IE. Alternatifnya cuma membiarkan situs itu tetap rusak
    Beberapa dekade lalu para web developer membuat situs yang hanya jalan di IE dan berkata “pakai IE kalau mau memakai situs ini”, dan sekarang hal yang sama terulang dengan Chrome. Apakah Chrome benar atau salah tidak penting. Situsnya hanya berjalan di Chrome, dan kalau browser lain tidak menjamin perilaku Chrome di situs itu, orang akan bilang “browser ini rusak” lalu pindah ke Chrome
    Saya benar-benar penasaran apakah orang menganggap Gecko dan WebKit harus membiarkan situs-situs ini tetap rusak demi prinsip, atau justru menganggap semua orang seharusnya hanya memakai Chrome dan tidak memakai browser lain. Untuk hack khusus per situs, alternatifnya cuma dua itu

  • Menurut saya lucu bahwa Firefox dan Safari berpura-pura menjadi Chrome lewat user agent
    Tapi di string user agent Chrome sendiri masih tersisa fosil-fosil dari masa ketika ia berpura-pura menjadi browser Mozilla dan browser Apple
    Ada lapisan geologis yang menumpuk dalam satu baris kode ini:

    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;