อาการหน้าเว็บว่างเปล่าเมื่อเข้า www.google.com

 (github.com/webcompat)
1 คะแนน โดย GN⁺ 2024-01-10 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • มีการลงทะเบียนประเด็น webcompat ที่ใน Firefox Mobile 121.0 บน Android เมื่อเข้าถึง https://www.google.com/ แล้วหน้าเว็บแสดงเป็นหน้าจอว่าง ทำให้ไม่สามารถใช้ฟังก์ชันหลักของ Google Search ได้
  • จากการทดสอบจำลอง พบปัญหาเดียวกันทั้งใน Firefox Release 121.0.1 และ Firefox Nightly 123.0a1 แต่ไม่พบใน Chrome 120.0.6099.43
  • เมื่อปิดใช้งาน ETP จะมี แบนเนอร์คุกกี้ แสดงขึ้นมา แต่แม้กดยินยอมแล้ว เนื้อหาหลักของหน้าก็ยังคงเป็นหน้าจอว่างอยู่ ปัญหาจึงยังไม่ถูกแก้
  • ประเด็น Mozilla Bugzilla ที่เกี่ยวข้องถูกเชื่อมโยงเป็น 1873601 และมีแพตช์ที่พร้อมเผยแพร่เป็น dot-release หากจำเป็น
  • ต่อมา Google เริ่มปล่อยการแก้ไข และหลังจากเฝ้าสังเกตอยู่หลายชั่วโมง พบว่าปัญหาดูเหมือนจะแก้ไขแล้วสำหรับ ผู้ใช้ส่วนใหญ่ จึงมีการตัดสินใจปิดประเด็นนี้เป็น fixed

ปัญหาที่เกิดขึ้นและสภาพแวดล้อมรายงานครั้งแรก

  • URL เป้าหมายคือ https://www.google.com/ และประเภทปัญหาถูกลงทะเบียนเป็น Site is not usable
  • อาการที่รายงานคือหน้า Google โหลดไม่ปกติและแสดงเป็น หน้าจอว่าง
  • สภาพแวดล้อมที่รายงานครั้งแรก:
    • เบราว์เซอร์: 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

ผลการจำลองปัญหาและเบราว์เซอร์ที่ใช้เปรียบเทียบ

  • ผู้รับผิดชอบการจำลองสามารถทำให้เกิดปัญหานี้ซ้ำได้
  • สภาพแวดล้อมทดสอบ:
    • 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
  • ประเด็นนี้ถูกจัดอยู่ในกลุ่ม Firefox Mobile, เอนจิน Gecko, และ การโหลดหน้าเว็บล้มเหลว

การทดสอบปิดใช้งาน ETP

  • เมื่อปิดใช้งาน ETP แบนเนอร์คุกกี้จะปรากฏขึ้น
  • แม้ยอมรับแบนเนอร์คุกกี้แล้ว เนื้อหาหลักของหน้า Google ก็ยังไม่แสดง และยังคงเป็น หน้าจอว่าง
  • จากผลทดสอบนี้เพียงอย่างเดียว การปิดใช้งาน ETP จึงไม่ใช่วิธีแก้ปัญหา

การวินิจฉัยและประเด็นที่เกี่ยวข้อง

  • ประเด็นนี้ถูกย้ายไปยังขั้น needsdiagnosis
  • บั๊ก Mozilla Bugzilla ที่เกี่ยวข้องถูกอ้างอิงข้ามเป็น 1873601
  • ในวันเดียวกัน มีการเชื่อมโยงประเด็นเกี่ยวกับ Google ที่คล้ายกันหลายรายการ:

ความคืบหน้าการแก้ไขและแนวทางจัดการ

  • ผู้รับผิดชอบระบุว่ามีแพตช์ที่พร้อมเผยแพร่เป็น dot-release หากจำเป็น
  • จากสถานะในขณะนั้น มีการประเมินว่าแพตช์ดังกล่าวอาจไม่จำเป็น
  • ต่อมา Google เริ่มปล่อยการแก้ไข และหลังจากเฝ้าดูความคืบหน้าเป็นเวลาหลายชั่วโมง พบว่าปัญหาดูเหมือนจะแก้ไขแล้วสำหรับ ผู้ใช้ส่วนใหญ่
  • การล็อกการสนทนาถูกปลดออกไว้สำหรับกรณีที่ยังมีผู้ใช้พบปัญหาหน้าจอว่างของ Google Search และสามารถแก้ได้ด้วย UA spoof
  • หากอาการเดิมยังคงเกิดขึ้น การลงทะเบียนบั๊กใหม่อาจถูกจับได้ดีกว่าในกระบวนการ triage แทนที่จะคอมเมนต์ในประเด็นเดิม

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-01-10
ความคิดเห็นบน Hacker News

  • ประเด็นหลักคือ อย่างที่ระบุไว้ใน https://github.com/webcompat/web-bugs/issues/131916#issuecomment-1882627241 นี่เป็นกรณีที่ การแยกแยะ UA ฝั่งเซิร์ฟเวอร์ ผิดพลาดอย่างสิ้นเชิง
    ถ้าส่งคำขอด้วย Firefox Android UA จะได้เอกสาร HTML ว่าง ๆ ที่มีแค่ doctype กลับมา และทำซ้ำได้ด้วย curl
    $ curl -H "User-Agent: Mozilla/5.0 (Android 10; Mobile; rv:123.0) Gecko/123.0 Firefox/123.0" https://www.google.com
    ดูเหมือนว่า สตริง UA ที่เป็นเวอร์ชัน 65 ขึ้นไป ทั้งหมดได้รับผลกระทบ ส่วน 64 ลงมายังทำงานได้

    • พูดให้แม่นคือเป็น Firefox Mobile
      สตริง UA ที่ Firefox Mobile ส่งเมื่ออยู่ในโหมดเดสก์ท็อปได้รับการตอบกลับตามปกติ
    • เมื่อไม่กี่สัปดาห์ก่อนก็เคยเห็นอาการนี้กับ Gmail บน Linux Firefox อยู่ประมาณหนึ่งสัปดาห์

  • ผมทำงานอยู่ที่ Google Search ขออภัยสำหรับเรื่องนี้ ตอนนี้แก้ไขแล้ว และถูกนำขึ้นแดชบอร์ดสถานะการค้นหาด้วย: https://status.search.google.com/incidents/hySMmncEDZ7Xpaf9i32C

    • โชคดีที่มีการรายงานในสถานที่ที่เหมาะสมและเป็นที่เดียวที่จะได้รับการสนับสนุนจาก Google ได้ นั่นคือ หน้าแรกของ Hacker News
    • อยากได้ยินว่าเป็นบั๊กอะไรและแก้ไขอย่างไร
    • เวลาเกิดเรื่องแบบนี้คงเครียดมาก ซอฟต์แวร์เป็นงานที่ยาก และมีปัจจัยที่อาจผิดพลาดได้มหาศาล
      พอคิดว่าบริการขนาดใหญ่มีข้อผิดพลาดและการหยุดชะงักค่อนข้างน้อย ก็ทำให้รู้สึกได้ว่างานเบื้องหลังนั้นหนักมากทีเดียว

  • Google ร่วมมือกับ Mozilla เพื่อมอบ ประสบการณ์ค้นหาแบบไม่มีโฆษณา

    • บังเอิญกลายเป็นประสบการณ์ที่ไม่มีการค้นหาด้วย

  • Google กำลังติดตามเหตุการณ์นี้ที่นี่: https://status.search.google.com/incidents/hySMmncEDZ7Xpaf9i32C
    เปิดเผยไว้ก่อนว่าทำงานที่ Google แต่ไม่ได้รับผิดชอบเรื่องนี้ เห็นลิงก์นี้จากบั๊กใน Bugzilla

    • ไม่เข้าใจว่าทำไมถึงไม่ใช่แค่ rollback ต่อให้แย่ที่สุดก็น่าจะ revert commit แล้ว deploy ใหม่ก็พอ
      เข้าใจได้ว่าปัญหาเกิดกับเบราว์เซอร์ที่พบน้อยกว่าเล็กน้อย แต่สำหรับวิศวกร Google การแก้ไขเองก็น่าจะเป็นเรื่องเล็กน้อยไม่ใช่หรือ

  • ถึงผู้ส่ง: “หากชื่อเรื่องต้นฉบับไม่ทำให้เข้าใจผิดหรือเป็น clickbait ให้ใช้ชื่อเรื่องต้นฉบับ และอย่าแก้ไข” — https://news.ycombinator.com/newsguidelines.html
    ถ้าอยากพูดถึงสิ่งที่คิดว่าสำคัญในบทความ ก็เขียนเป็นคอมเมนต์ในเธรดได้ แบบนั้นจะถูกมองเห็นภายใต้เงื่อนไขเดียวกับคนอื่น ๆ: 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 เขียนว่า Google จงใจทำให้เกิดปัญหาเพื่อผลักผู้ใช้ให้ย้ายไป Chrome
    https://news.ycombinator.com/item?id=38349357

    • คิดว่ากรณีนี้ก็เป็นแบบนั้นด้วยหรือ Google ทำให้ หน้าค้นหาเป็นหน้าว่าง เพื่อส่งผู้ใช้ Firefox ไป Chrome อย่างนั้นหรือ
      หรืออาจเป็นเรื่องที่ใกล้เคียงกับ มีดโกนของแฮนลอน มากกว่า

  • https://github.com/webcompat/web-bugs/issues/131916#issuecomment-1882627241
    นี่เป็นตัวอย่างของการแยกแยะ UA ฝั่งเซิร์ฟเวอร์ที่ผิดพลาดล้วน ๆ เมื่อส่งคำขอด้วย Firefox Android UA จะได้รับเอกสาร HTML ว่างที่มีแค่ doctype
    ทำซ้ำได้ด้วย curl และดูเหมือนว่าสตริง UA ทุกตัวที่เป็นเวอร์ชัน 65 ขึ้นไปได้รับผลกระทบ ส่วน 64 ลงมาทำงานได้

    • น่าสนใจตรงที่ถ้าลบ “Android” ออกจาก UA จะได้เนื้อหามากขึ้น, ถ้าลบ “Mobile” ก็ยังได้แค่ doctype อยู่ และถ้าลบ “Firefox” จะหายสนิท

  • มีเหตุผลที่ชอบธรรมอะไรไหมในการใช้การแยกแยะสตริง UA แทน feature detection? แล้วเครื่องมือค้นหาต้องใช้ฟีเจอร์ใหม่แค่ไหนกัน ถึงขั้นอาจไม่ทำงานในทุกเบราว์เซอร์ได้?

    • เคยมีหลายกรณี กรณีแรกที่กระทบผมคือการที่ Chrome เปลี่ยนให้ต้องมีแฟล็ก SameSite=None ใน header Set-Cookie ในบริบทแบบ third-party[1]

      คำเตือน: Chrome, Safari, UC browser บางเวอร์ชันเก่าไม่เข้ากันกับแอตทริบิวต์ None ใหม่ และอาจเพิกเฉยหรือจำกัดคุกกี้
      ด้วยข้อจำกัดนี้ หากต้องการตั้งคุกกี้ที่รับประกันว่าจะทำงานถูกต้อง การแยกแยะ UA เป็นวิธีเดียวที่เชื่อถือได้
      1: https://web.dev/articles/samesite-cookies-explained

    • เพื่อจะติดตามผู้ใช้ด้วยวิธีใหม่ ๆ ที่น่าตื่นเต้น
    • เคยเห็นกรณีที่เบราว์เซอร์ทำงานต่างกันแบบละเอียดอ่อน ระหว่างหาวิธีแก้ที่ถูกต้อง เพื่อลดผลกระทบ เราเคยส่ง เนื้อหาที่ต่างกันตามเบราว์เซอร์ ให้ผู้ใช้เหล่านั้น เพื่อให้ได้ประสบการณ์ที่ใช้งานได้
      เรื่องนี้ไม่เกี่ยวกับ feature detection ดังนั้นคำแนะนำที่มักได้ยินจึงใช้ไม่ได้
    • กรณีตรวจจับระบบปฏิบัติการของผู้ใช้เพื่อให้ ลิงก์ดาวน์โหลดไบนารี ที่ถูกต้อง?
    • สิ่งหนึ่งที่โดดเด่นบนหน้าแรก Google Search คือมันเร็วมาก หลังจากพิมพ์คีย์แรก ภายใน 200ms จะตอบกลับด้วยคำแนะนำ 10 รายการที่มีทั้งข้อความและรูปภาพ และทำได้ต่อเนื่องแบบนั้น
      เวลาไป-กลับของผมไปยัง www.google.com อยู่ราว 20ms ดังนั้นอย่างน้อย 100ms ในนั้นย่อมถูกใช้ไปบนอินเทอร์เน็ต
      ความเร็วแบบนี้เป็นไปไม่ได้หากไม่มีการปรับแต่งอย่างหนัก จริง ๆ แล้วถ้า www.google.com ไม่ใช่หน้าที่ถูก optimize มากที่สุดบนอินเทอร์เน็ตก็คงน่าประหลาดใจ
      ดังนั้นจึงไม่น่าแปลกใจเลยที่จะ optimize ตามว่าเบราว์เซอร์ใดเป็นผู้ส่งคำขอ

  • ไม่คิดว่าจะหัวเราะ แต่ สกรีนช็อต ที่มีแค่สี่เหลี่ยมสีขาวล้วน ๆ นั้นตลกอย่างประหลาด