ब्राउज़र बड़े साइट्स को अलग तरीके से ट्रीट करते हैं

 (denodell.com)
4 पॉइंट द्वारा GN⁺ 3 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Safari और Firefox, TikTok, Netflix, Instagram जैसे विशिष्ट domains पर rendering और API behavior बदलने वाला code ship करते हैं
  • Firefox का about:compat site-specific interventions और toggles दिखाता है, और custom CSS·JavaScript injection तथा user agent spoofing करता है
  • Safari का WebKit इन्हें quirks के रूप में manage करता है, और PiP video·image alignment·popover·streaming access जैसी समस्याओं को domain के आधार पर bypass करता है
  • Chrome को अलग exception files की लगभग ज़रूरत नहीं पड़ती, क्योंकि web पहले से ही Chrome-केंद्रित बना हुआ है और दूसरे browsers अंतर को compensate करते हैं
  • ये exceptions logs या console में आसानी से नहीं दिखते, इसलिए developers को Firefox और Safari में नियमित रूप से test करना चाहिए और quirks files में inclusion की जांच करनी चाहिए

ब्राउज़र के भीतर domain-specific exception handling

  • Safari और Firefox, user द्वारा visit किए गए domain के आधार पर rendering या API behavior बदलने वाला code ship करते हैं
  • TikTok, Netflix, Instagram, SeatGuru जैसी sites इस तरह के site-specific handling की target होती हैं
  • संबंधित source, WebKit के Quirks.cpp और Firefox के WebCompat interventions में सार्वजनिक रूप से देखा जा सकता है
  • यह code browser rendering engine में इस तरह शामिल है कि “अगर specific domain हो तो अलग render करो” या “अगर specific domain हो तो API calls को अलग तरह से handle करो”
  • Chrome को इस तरह की exception files की लगभग ज़रूरत नहीं पड़ती, जिससे यह असमानता सामने आती है कि web पहले से ही Chrome-केंद्रित बनाया गया है

Firefox का about:compat

  • Firefox के address bar में about:compat डालने पर site-specific interventions की list और toggle switches देखे जा सकते हैं
  • हर item किसी specific website के लिए custom fix है, और उसे बंद करने पर देखा जा सकता है कि site कैसे टूटती है
  • Firefox का WebCompat system specific domains के लिए custom CSS और JavaScript inject करता है
  • जो sites browser को गलत पहचानती हैं, उनके लिए user agent string बदलकर भेजी जाती है
  • ये interventions bugs को इस तरह ढकते हैं कि web टूटा हुआ न लगे, और Mozilla Bugzilla में bug reports से लेकर site से संपर्क करने की कोशिशों तक track किया गया है

Safari के quirks

  • Safari का WebKit engine इस तरह की handling को quirks कहता है, और Quirks.cpp GitHub पर सार्वजनिक है
  • WebKit code में एक comment है कि Facebook, X, Reddit screen के बाहर scroll किए गए <video> को PiP mode हो या न हो, pause कर देते हैं
  • Safari, facebook.com, x.com, reddit.com detect करके Picture-in-Picture video handling बदल देता है
  • अगर site का video code टूटा हुआ हो, तो भी उन कंपनियों के fix करने का इंतज़ार करने के बजाय browser सभी users के लिए workaround ship करता है
  • SeatGuru से संबंधित comment में FIXME: Remove this quirk if seatguru decides to adjust their site. लिखा है, जो दिखाता है कि site ठीक होने पर exception हटाई जा सकती है
  • commit history में पिछले कुछ महीनों में कई site-specific fixes जोड़ी गई हैं
    • Zillow की floorplan images center align न होने की समस्या
    • TikTok पर “please upgrade your browser” message दिखने की समस्या
    • Instagram Reels के playback के दौरान अनियमित रूप से resize होने की समस्या
    • Netflix में “Episodes and Info” button द्वारा popover को गलत तरीके से बंद करने की समस्या
    • Twitch का tab switch पर PiP video pause करना
    • Amazon Prime Video का Safari users को देखने की अनुमति न देना

Chrome-केंद्रित web और असमानता

  • WebKit के quirks और Firefox के WebCompat सिर्फ टूटी हुई sites को fix नहीं करते, बल्कि उस स्थिति को भी correct करते हैं जहाँ Chrome “काम करता है” का मानक तय करता है
  • आम तौर पर जब Chrome कोई feature ship करता है, तो market dominance की वजह से developers वही feature इस्तेमाल करते हैं, और दूसरे browsers उस feature को implement करते हैं या site-specific exceptions से अंतर को ढकते हैं
  • जब तक Safari और Firefox catch up करते हैं, तब तक exceptions पहले ही लाखों users तक ship हो चुकी होती हैं
  • WebKit में user agent overrides शामिल हैं, जो Amazon video pages और कई streaming services पर Safari को Chrome की तरह दिखाते हैं
  • ये sites Chrome होने या न होने का पता लगाकर दूसरे browsers को degraded experience देती हैं, इसलिए WebKit Safari users की सुरक्षा के लिए browser identity को spoof करता है
  • अभी Quirks.cpp में यह fake Chrome user agent string शामिल है
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 में कई interventions user agent spoofing हैं जो sites से कहती हैं “मैं Chrome हूँ”
  • Mozilla wiki बताती है कि कुछ sites browser detection result के आधार पर “access को पूरी तरह block कर देती हैं, अलग design दिखाती हैं, या अलग functionality देती हैं”
  • यह structure एक feedback loop बनाता है
    • developers, Chrome की ऊँची market share की वजह से Chrome को baseline मानकर बनाते हैं
    • sites Chrome में सबसे अच्छा काम करती हैं
    • दूसरे browsers में bugs देखने वाले users, site की बजाय browser को दोष देते हैं
    • users Chrome पर चले जाते हैं, और Chrome की dominance और मज़बूत होती है
  • Chrome को अलग quirks files की लगभग ज़रूरत नहीं पड़ती, इसका कारण यह नहीं कि Chrome बेहतर design किया गया है, बल्कि यह है कि web पहले से ही Chrome के हिसाब से ढला हुआ है
  • Chromium-based browsers के 80% से अधिक usage की स्थिति में developers पहले Chrome को target करते हैं
  • अगर site Chrome में काम करती है, तो उसे ship कर दिया जाता है, और अगर Safari या Firefox में टूटती है, तो उस समस्या की priority कम हो जाती है
  • Chrome exceptions जोड़ने से ज़्यादा agenda set करता है
  • Chrome किसी behavior को बदल दे, तो sites उसके हिसाब से update होती हैं, और दूसरे browsers या तो follow करते हैं या टूट जाते हैं

specs और वास्तविक web के बीच की खाई

  • browser engineers मान सकते हैं कि आज specs अच्छी तरह define हैं, और HTML5 की “living specification” approach ने IE/Netscape दौर की अराजकता कम की है
  • समस्या यह है कि developers, specs में न होने वाली implementation details पर depend करते हैं, और अगर वे details दूसरे browsers में अलग हों तो non-conforming browser को दोष देते हैं
  • जब Chrome का implementation सबके target का baseline बन जाता है, तो Chrome का spec के बाहर का detailed behavior ही de facto spec बन जाता है
  • 2000s के Internet Explorer दौर में भी developers IE के हिसाब से sites बनाते थे, जिससे दूसरे browsers में sites टूट जाती थीं, और standards compliance से ज़्यादा “IE में काम करना” प्राथमिकता बन जाता था
  • पहले उम्मीद थी कि अगर web standards का बेहतर पालन करेगा तो browser quirks गायब हो जाएँगे, लेकिन वास्तव में quirks गायब नहीं हुईं, वे बस non-Chrome browsers की तरफ शिफ्ट हो गईं
  • standards का मकसद browser-specific code को हटाना था, लेकिन IE दौर से निकलने के बाद वही छेद दूसरे browser ecosystem के इर्द-गिर्द फिर बन गया
  • अब browser-specific code dominant browser में नहीं, बल्कि उस non-dominant browser के अंदर है जो dominant browser के हिसाब से बने web को correct कर रहा है

exception handling जितनी दिखती है, उससे कहीं गहरी है

  • इस तरह की handling सिर्फ visual tweaks तक सीमित नहीं है, बल्कि domain के आधार पर browser के default behavior को बदल देती है
  • केवल WebKit की list ही हजारों lines लंबी है, जिसमें scroll behavior, touch event handling, viewport calculation, image MIME type handling तक शामिल हैं
  • Amazon product image zoom feature के लिए comment में यह लिखा है
When panning on an Amazon product image, we’re either touching on the #magnifierLens element or its previous sibling.
  • Safari यह जांचने के बाद कि user Amazon पर है, product zoom feature के लिए touch events को mouse events में convert करने का अपना तरीका बदल देता है
  • क्योंकि Amazon site Safari के default behavior से अलग एक specific event behavior मानकर चलती है, Safari सिर्फ Amazon के लिए वही behavior उपलब्ध कराता है
  • storage access, scrollbar rendering, autocorrection behavior, और zoom handling में भी domain-specific quirks मौजूद हैं
  • हर exception domain check के पीछे छिपी होती है, और browser executable के भीतर compile की जाती है

इंतज़ार करने के बजाय browser खुद fix क्यों करता है

  • browser vendors कभी-कभी problematic sites से संपर्क करके fix का अनुरोध भी करते हैं, और source code में outreach efforts से जुड़े fields भी मिलते हैं
  • लेकिन अगर कोई लोकप्रिय site Chrome में काम करे और उनके अपने browser में टूटे, तो users site नहीं बल्कि browser को दोष देते हैं
  • किसी third party को bug submit करके कई हफ्ते या महीनों का इंतज़ार करने से बेहतर browser के लिए यह ज़्यादा practical है कि अगले दिन 5-line workaround ship कर दिया जाए
  • यह भी हमेशा स्पष्ट नहीं होता कि संपर्क किससे किया जाए
    • टूटा हुआ code लिखने वाला developer शायद कंपनी छोड़ चुका हो
    • संबंधित endpoint की owner team अपनी जिम्मेदारी पहचानती न हो
    • site maintenance mode में हो, जहाँ सिर्फ security patches मिल रहे हों
  • browser के लिए users की समस्या तुरंत और बिना दिखे कम कर देना एक सीधा विकल्प है
  • WebKit engineer ने FlightAware quirk हटाने की प्रक्रिया पर भी लिखा है
  • FlightAware, CSS transform matrix string की तुलना कर रहा था, और जब CSS spec ने value serialization का तरीका बदला और browser ने spec follow किया, तो site टूट गई
  • engineers ने flightaware.com की जांच करने वाला domain-specific code जोड़ा, और बाद में संपर्क सफल होने पर FlightAware ने अपना code ठीक किया, जिसके बाद quirk हटा दी गई
  • उन कुछ महीनों के दौरान Safari users को browser के अंदर मौजूद if statement की वजह से सामान्य experience मिला

developers को क्या जांचना चाहिए

  • संभव है कि आपकी website को आपकी जानकारी के बिना special rendering treatment मिल रहा हो
  • ऐसी quirks error logs में दिखाई नहीं देतीं, और console में भी “browser अभी गलती को workaround कर रहा है” जैसी warning नहीं आती
  • workarounds जानबूझकर invisible तरीके से काम करते हैं
  • खासकर वे sites जोखिम में हैं जो मुख्य रूप से Chrome पर test करती हैं
  • site के पूरी तरह काम करने की वजह अच्छा code नहीं, बल्कि यह भी हो सकती है कि Chrome का behavior developer की assumptions से मेल खाता हो
  • दूसरे browsers के सामने यह विकल्प होता है कि site को users को टूटी हुई दिखाएँ, या उसे quirks files में जोड़ दें
  • Firefox और Safari में site को कभी-कभार नहीं, बल्कि नियमित रूप से खोलकर देखना चाहिए
  • quirks files इसलिए मौजूद हैं क्योंकि developers नियमित रूप से ऐसा नहीं करते
  • अगर आपका domain quirks files में है, तो browser ने जहाँ workaround किया है, उस हिस्से की जांच करना ज़रूरी है
  • web developers के direct intervention के बिना भी चलता रहा, लेकिन संभव है कि जिन browsers का आप इस्तेमाल नहीं करते, उनके engineers उन समस्याओं को आपके लिए ठीक करते रहे हों जिनके बारे में आपको पता भी नहीं था

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 3 시간 전
Lobste.rs की राय

  • LLM बकवास के पीछे एक दिलचस्प कहानी छिपी हुई है

    • दुर्भाग्य से, लेख इतना खराब था कि वह कहानी मिल ही नहीं पाई। यह ऐसा लेख था जिसे शीर्षक पर ही रुक जाना चाहिए था
    • इस टिप्पणी को upvote करने वालों को शायद इसे spam के रूप में रिपोर्ट करना चाहिए
    • सनसनीखेज़ अंदाज़ में शुरू होकर अचानक शांत स्वर में ब्राउज़र compatibility workaround जानकारी समझाने लगना काफ़ी खटकने वाला था
    • विनम्रता से कहूँ तो, आजकल बिना आधार के किसी चीज़ को “LLM बकवास” कह देने वाली टिप्पणियाँ बढ़ती जा रही हैं। शायद लोग यह भूल रहे हैं कि LLM का लेखन जैसा दिखना इसलिए है क्योंकि उसे लेखन पर ही train किया गया है
      आपको लिखने का अंदाज़ पसंद न आए, यह अलग बात है और उस पर बहस करने की ज़रूरत नहीं, लेकिन सिर्फ़ इसलिए कि लेख खराब है, यह ज़रूरी नहीं कि वह AI ने लिखा हो। AI से पहले भी खराब लिखे गए वाक्य बहुत थे
    • काश कोई साफ़-साफ़ बताए कि इस टिप्पणी और उससे जुड़े thread को असल में दिक्कत किस बात से है। लेख पढ़ने में आसान था और उपयोगी भी, इसलिए समझ नहीं आ रहा कि समस्या क्या है

  • यह दुर्भाग्यपूर्ण है, और काश हम ऐसी दुनिया में रहते जहाँ Google वेब पर इतना ज़्यादा असर न रखता। “वेब” का सपना इससे कहीं अधिक महत्वाकांक्षी था, और मेरे लिए व्यक्तिगत रूप से अधिक प्रेरणादायक भी, इसलिए उसका आज इस हाल में पहुँचना अफ़सोसजनक है

  • quotation block पढ़ने में मुश्किल है। शायद यह dark mode की समस्या हो सकती है
    workaround की बारीकियाँ साझा करना उपयोगी था

    • सही है, contrast लगभग है ही नहीं। light mode में भी बहुत अच्छा नहीं है, बस dark mode से थोड़ा बेहतर है। लगता है साइट बनाने वाले ने इसे ख़ुद देखकर नहीं, बस आँख बंद करके कोड कर दिया

  • “ये साइटें पता लगाती हैं कि ब्राउज़र Chrome है या नहीं, और दूसरे ब्राउज़रों को downgraded experience देती हैं। इसलिए Safari उपयोगकर्ताओं को परेशान होने देने के बजाय WebKit अपने ब्राउज़र होने के बारे में झूठ बोलता है” — यह इस पूरे उद्योग में बार-बार होने वाली बात लगती है
    कंप्यूटर निर्माता भी अक्सर ऐसे ACPI firmware जारी करते हैं जो unsupported operating system से जानकारी छिपाते हैं, और अंत में उन operating system को firmware को धोखा देने के लिए Windows होने का नाटक करना पड़ता है

  • यह बात पसंद नहीं आई कि यह लेख AI writing style जैसा लगता है

  • यहाँ बताई गई बातों के अलावा दो feedback loops और हैं। एक यह कि Chrome dominant है, इसलिए developer Chrome को ध्यान में रखकर बनाते हैं, फिर चीज़ें Chrome पर सबसे अच्छा चलती हैं, और जब दूसरे ब्राउज़र में समस्या आती है तो user साइट को नहीं बल्कि ब्राउज़र को दोष देते हैं और Chrome पर चले जाते हैं
    दूसरा यह कि साइट Firefox में टूटी हुई है, लेकिन फिर भी साइट चलाने वाला कहता है कि उसे आँकड़ों में Firefox user दिख ही नहीं रहे। user agent बदलने जैसी special handling हो तब भी ऐसा हो सकता है

  • अगर मुझे सही याद है, तो पुराना Opera(Presto) ही था जिसने इस तरह की compatibility layer को सबसे पहले लागू करना शुरू किया था

  • implementation का ही specification बन जाना इस क्षेत्र की बहुत आम समस्या है। मेरी पिछली नौकरी में हम एक ऐसी workflow language इस्तेमाल करते थे जिसमें conformance tests थे, इस उम्मीद में कि कई implementations बनेंगे और workflow portable हो जाएँगे
    मूल समस्या यह है कि पूरी portability बनाने के लिए आर्थिक प्रोत्साहन कम होता है। आप अपनी implementation में extra features डालकर चाहते हैं कि लोग उसी product में बने रहें
    और चूँकि committee-style तरीके से software बनाने का समय नहीं होता, इसलिए लोग नए features पहले से बनाकर शामिल करना चाहते हैं
    implementation का specification बन जाना इसलिए होता है क्योंकि हम मानव समाज में रहते हैं

  • यह कोई नई बात नहीं है। छोटे ब्राउज़र हमेशा से कुछ खास साइटों के लिए hack रखते आए हैं, और पहले यह IE के लिए होता था। विकल्प बस यही था कि साइट टूटी हुई पड़ी रहे
    दशकों पहले web developer ऐसी साइटें बनाते थे जो सिर्फ़ IE में चलती थीं, और कहते थे “यह साइट इस्तेमाल करनी है तो IE इस्तेमाल करो”, और अब वही बात Chrome के साथ दोहराई जा रही है। Chrome सही है या ग़लत, यह अहम नहीं है। साइट Chrome में चलती है, और अगर दूसरे ब्राउज़र उस साइट पर Chrome जैसा व्यवहार सुनिश्चित नहीं करते, तो लोग कहते हैं “यह ब्राउज़र टूटा हुआ है” और Chrome पर चले जाते हैं
    मुझे सच में समझ नहीं आता कि लोग यह मानते हैं कि Gecko और WebKit को सिद्धांतों की ख़ातिर ऐसी साइटों को टूटा हुआ ही छोड़ देना चाहिए, या फिर सबको सिर्फ़ Chrome ही इस्तेमाल करना चाहिए और दूसरे ब्राउज़र छोड़ देने चाहिए। साइट-विशेष hacks का विकल्प बस यही दो हैं

  • मुझे यह मज़ेदार लगता है कि Firefox और Safari user agent में Chrome होने का नाटक करते हैं
    लेकिन Chrome के user agent string में भी वह जीवाश्म-जैसा अवशेष अब तक बचा है जहाँ वह Mozilla browser और Apple browser होने का नाटक करता था
    कोड की इस एक पंक्ति में भूगर्भीय परतें जमी हुई हैं:

    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;