1 पॉइंट द्वारा GN⁺ 2024-01-10 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Android पर Firefox Mobile 121.0 में https://www.google.com/ खोलने पर पेज खाली स्क्रीन के रूप में दिख रहा था, जिससे Google Search की मुख्य सुविधाएँ इस्तेमाल नहीं हो पा रही थीं और इसके लिए एक webcompat issue दर्ज किया गया
  • पुनरुत्पादन परीक्षण में Firefox Release 121.0.1 और Firefox Nightly 123.0a1 दोनों में वही समस्या हुई, जबकि Chrome 120.0.6099.43 में यह दोहराई नहीं गई
  • ETP को disable करने पर cookie banner दिखाई देता है, लेकिन सहमति देने के बाद भी पेज का मुख्य भाग खाली ही रहता है, इसलिए समस्या हल नहीं होती
  • संबंधित Mozilla Bugzilla issue 1873601 से जोड़ा गया, और ज़रूरत पड़ने पर dot-release के रूप में जारी करने के लिए patch तैयार था
  • इसके बाद Google ने fix rollout करना शुरू किया, और कुछ घंटों तक अवलोकन के बाद लगा कि समस्या ज़्यादातर उपयोगकर्ताओं के लिए हल हो गई है, इसलिए issue को fixed के रूप में बंद करने का निर्णय लिया गया

हुई समस्या और शुरुआती रिपोर्ट का environment

  • लक्षित URL https://www.google.com/ है, और समस्या प्रकार Site is not usable के रूप में दर्ज किया गया
  • रिपोर्ट किया गया लक्षण यह था कि Google पेज सामान्य रूप से load नहीं हो रहा था और खाली स्क्रीन के रूप में दिख रहा था
  • शुरुआती रिपोर्ट का environment:
    • ब्राउज़र: Firefox Mobile 121.0
    • ऑपरेटिंग सिस्टम: Android 13
    • अन्य ब्राउज़र परीक्षण: Yes Other
  • ब्राउज़र सेटिंग्स में ये मान शामिल थे:
    • gfx.webrender.all: false
    • gfx.webrender.blob-images: true
    • gfx.webrender.enabled: false
    • buildID: 20231230165955
    • channel: release
    • hasTouchScreen: true
    • mixed active/passive content blocked: false
    • tracking content blocked: false

पुनरुत्पादन परिणाम और तुलना वाले ब्राउज़र

  • पुनरुत्पादन करने वाले व्यक्ति ने इस समस्या को दोहरा लिया
  • परीक्षण environment:
    • Firefox Nightly 123.0a1-20240108213208
    • Firefox Release 121.0.1-20231230165955
    • Chrome 120.0.6099.43
    • डिवाइस: OnePlus 6 A6000
    • ऑपरेटिंग सिस्टम: Android 11
    • स्क्रीन: 1080 x 2280, 19:9, लगभग 402 ppi
  • पुनरुत्पादन परिणाम:
    • Firefox Release और Nightly दोनों में समस्या दोहराई गई
    • Chrome में समस्या दोहराई नहीं गई
  • issue को Firefox Mobile, Gecko engine, और page load failure श्रेणी में वर्गीकृत किया गया

ETP disable परीक्षण

  • ETP को disable करने पर cookie banner दिखाई देता है
  • cookie banner स्वीकार करने के बाद भी Google पेज का मुख्य भाग नहीं दिखता और वह अब भी खाली स्क्रीन की स्थिति में रहता है
  • केवल इस परीक्षण के आधार पर ETP को disable करना समस्या का समाधान नहीं माना जा सकता

निदान और संबंधित issues

  • issue को needsdiagnosis चरण में ले जाया गया
  • संबंधित Mozilla Bugzilla bug को 1873601 के रूप में cross-reference किया गया
  • उसी दिन Google से जुड़े कई समान issues भी लिंक किए गए:

fix की प्रगति और आगे की दिशा

  • प्रभारी ने बताया कि ज़रूरत पड़ने पर dot-release के रूप में जारी करने के लिए patch तैयार है
  • उस समय यह आंका गया कि शायद उस patch की आवश्यकता न पड़े
  • इसके बाद Google ने fix rollout करना शुरू किया, और कुछ घंटों तक स्थिति देखने के बाद लगा कि समस्या ज़्यादातर उपयोगकर्ताओं के लिए हल हो गई है
  • जो उपयोगकर्ता अब भी Google Search में खाली स्क्रीन की समस्या झेल रहे हैं और जिनके मामले में UA spoof से समाधान संभव है, उनके लिए discussion lock हटा दिया गया
  • यदि वही लक्षण जारी रहें, तो मौजूदा issue पर टिप्पणी छोड़ने के बजाय नया bug दर्ज करना triage प्रक्रिया में अधिक प्रभावी ढंग से पकड़ा जा सकता है

1 टिप्पणियां

 
GN⁺ 2024-01-10
Hacker News की राय
  • मुख्य बात यह है कि, जैसा https://github.com/webcompat/web-bugs/issues/131916#issuecomment-1882627241 में बताया गया है, यह पूरी तरह server-side UA detection के गलत होने का मामला है
    Firefox Android UA के साथ request करने पर सिर्फ doctype वाला खाली HTML document लौटता है, और इसे curl से भी reproduce किया जा सकता है
    $ curl -H "User-Agent: Mozilla/5.0 (Android 10; Mobile; rv:123.0) Gecko/123.0 Firefox/123.0" https://www.google.com
    लगता है कि 65 या उससे ऊपर के version वाले सभी UA strings प्रभावित हैं, जबकि 64 से नीचे वाले काम कर रहे हैं

    • ठीक-ठीक कहें तो यह Firefox Mobile है
      Firefox Mobile desktop mode में जो UA string भेजता है, उस पर सामान्य response मिला
    • कुछ हफ्ते पहले लगभग एक हफ्ते तक Linux Firefox में Gmail पर भी यही समस्या देखी थी
  • मैं Google Search में काम करता हूँ. इस घटना के लिए माफ़ी. अब इसे ठीक कर दिया गया है और search status dashboard पर भी डाल दिया गया है: https://status.search.google.com/incidents/hySMmncEDZ7Xpaf9i32C

    • अच्छी बात यह रही कि यह Hacker News के पहले पेज पर रिपोर्ट हुआ, जो शायद Google support पाने की सही और इकलौती जगह है
    • जानना चाहूँगा कि bug क्या था और इसे कैसे ठीक किया गया
    • ऐसा कुछ होने पर काफ़ी stress होता होगा. Software मुश्किल क्षेत्र है, और इसमें गलत होने वाली चीज़ें बहुत ज़्यादा हैं
      बड़े services में errors और outages अपेक्षाकृत कम होते हैं, यह सोचकर ही समझ आता है कि उसके पीछे कितना काम लगता होगा
  • Google, Mozilla के साथ मिलकर बिना विज्ञापन वाला search experience दे रहा है

    • संयोग से यह बिना search वाला experience भी बन गया
  • Google इस incident को यहाँ track कर रहा है: https://status.search.google.com/incidents/hySMmncEDZ7Xpaf9i32C
    स्पष्ट कर दूँ, मैं Google में काम करता हूँ लेकिन इस मामले का ज़िम्मेदार नहीं हूँ. यह लिंक मैंने Bugzilla bug में देखा

    • समझ नहीं आता कि यह बस rollback क्यों नहीं है. सबसे बुरा हो तो revert commit करके फिर से deploy कर देना चाहिए था
      थोड़ा कम आम browser में समस्या हुई, यह तो समझ आता है, लेकिन Google engineer के लिए fix खुद में मामूली नहीं होना चाहिए था?
  • सबमिट करने वाले के लिए: “यदि शीर्षक भ्रामक या clickbait नहीं है, तो मूल शीर्षक का इस्तेमाल करें, उसे संपादित न करें.” — https://news.ycombinator.com/newsguidelines.html
    अगर आप बताना चाहते हैं कि लेख में क्या महत्वपूर्ण लगा, तो thread में comment कर सकते हैं. तब वह दूसरों की तरह समान शर्तों पर दिखाई देगा: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&sort=byDate&type=comment&query=%22level%20playing%20field%22%20by:dang
    जमा किया गया शीर्षक था: “Google breaks search for Firefox users because of bad UA string sniffing”

  • Mozilla के एक पूर्व अधिकारी की वह blog post याद आ गई जिसमें लिखा था कि Google जानबूझकर समस्याएँ पैदा करता है ताकि users Chrome पर चले जाएँ
    https://news.ycombinator.com/item?id=38349357

    • क्या यहाँ भी लोग वही मान रहे हैं? कि Google ने Firefox users को Chrome की ओर धकेलने के लिए search page को blank screen बना दिया?
      या फिर यह Hanlon's razor के ज़्यादा करीब की बात हो सकती है
  • https://github.com/webcompat/web-bugs/issues/131916#issuecomment-1882627241
    यह पूरी तरह server-side UA detection के गलत होने का मामला है. Firefox Android UA के साथ request करने पर सिर्फ doctype वाला खाली HTML document मिलता है
    इसे curl से reproduce किया जा सकता है, और लगता है कि 65 या उससे ऊपर के version वाले सभी UA strings प्रभावित हैं. 64 से नीचे वाले काम करते हैं

    • दिलचस्प बात यह है कि UA से “Android” हटाने पर ज़्यादा content आता है, “Mobile” हटाने पर फिर भी सिर्फ doctype आता है, और “Firefox” हटाने पर समस्या पूरी तरह ठीक हो जाती है
  • feature detection की जगह UA string detection इस्तेमाल करने का कोई उचित कारण है? और search engine आखिर कितना modern feature इस्तेमाल कर रहा होगा कि वह सभी browsers में काम ही न करे?

    • इसके कुछ उदाहरण रहे हैं, और जिसने मुझे पहली बार प्रभावित किया वह बदलाव था जब Chrome ने third-party context में Set-Cookie header पर SameSite=None flag अनिवार्य कर दिया था[1]

      चेतावनी: Chrome, Safari, UC browser के कुछ पुराने versions नए None attribute के साथ compatible नहीं हैं और cookies को ignore या restrict कर सकते हैं
      इस limitation की वजह से, ऐसा cookie सेट करने के लिए जो सही तरह काम करे, UA detection ही एकमात्र भरोसेमंद तरीका था
      1: https://web.dev/articles/samesite-cookies-explained

    • users को नए और रोमांचक तरीकों से track करने के लिए
    • मैंने ऐसे मामले देखे हैं जहाँ browsers बारीक स्तर पर अलग व्यवहार करते हैं. सही fix ढूँढने तक impact कम करने के लिए, हमने ऐसे users को browser-specific अलग content दिया है जो उनके यहाँ काम करे
      इसका feature detection से कोई लेना-देना नहीं, इसलिए आम तौर पर दिए जाने वाले सुझाव यहाँ काम नहीं आते
    • user का operating system detect करके उसके अनुसार सही binary download link देना?
    • Google search homepage की एक खास बात है कि यह बेहद तेज़ है. पहली key press के 200ms के भीतर text और images सहित 10 suggestions के साथ जवाब देता है, और आगे भी इसी तरह काम करता रहता है
      मेरा www.google.com round-trip time लगभग 20ms है, इसलिए उसमें से कम-से-कम 100ms इंटरनेट में ही खर्च हो जाते होंगे
      इतनी speed बिना बहुत मजबूत optimization के नहीं मिलती. सच कहूँ तो अगर www.google.com इंटरनेट का सबसे ज़्यादा optimized page नहीं है, तो मुझे हैरानी होगी
      इसलिए कौन-सा browser request कर रहा है, उसके हिसाब से optimize करना बिल्कुल भी चौंकाने वाली बात नहीं है
  • मुझे उम्मीद नहीं थी कि मैं हँसूँगा, लेकिन सिर्फ एकदम सफेद rectangle वाली screenshot अजीब तरह से मज़ेदार लगी