如何從一個 Chrome 的 Bug 中找到解決方案

在前端開發，或者說 Web 開發中，咱們會常常遇到，在某個瀏覽器遇到了問題，可是別的瀏覽器沒有，過去，咱們考慮的多是 IE6 的兼容性，而在 Chrome 一騎絕塵的今天，Chrome 而其餘瀏覽器沒有的問題反而成爲了更大的問題。前端

在此以前遇到過幾個 Chrome Bug，我會以兩個 Chrome Bug 爲例說說實際是怎麼解決的：chrome

在請求提交時無限 stalled

以前在咱們的密碼修改界面，可能會遇到點擊提交以後請求無限 stalled 的狀況，實際上數據已經被提交上去並修改完成了。而這個頁面本質上是一個 MVC 的老頁面，可是咱們在全局配上了 CORS 跨域頭，致使正好觸發了一個 Chrome 的 Bug。——Issue 1099122: 302 (Redirects) left stalled under CORS。後端

固然，當你實際定位到 issue 的時候好像很簡單，可是實際上，依舊通過了盲目的 Google + Stackoverflow 階段，最終想到了在三年前曾經寫過的一篇文章：一次 Chrome 緩存鎖的有趣探索，裏面一樣記錄了一次神奇的 stalled 和他的 Debug 方法。仍是老規矩，抓了一波 network，惟一的區別是傳送門變成了：netlog-viewer.appspot.com/。經過一波分析，咱們找到了這個請求，而且匹配上了對應的 issue，那麼對應的一些討論也就列舉在下面，接下來，咱們能夠經過 issue 的討論來找到本身合適的解決方案，或者實在沒有解決方案，也找到了現象和爲何會有這個效果，只要避免這個狀況發生就能夠了。跨域

emoji 表情渲染間距存在問題

做爲前端，大部分坑爹的接口問題均可以甩給後端去解決，可是自開天闢地以來，前端兼容性問題一直是前端難以名狀的痛苦——明明是瀏覽器寫的 Bug，爲何要上層開發買單！瀏覽器

實際上咱們又遇到了相同的問題，當你使用 emoji + 文字的時候，在別的瀏覽器中（好比 Safari / Firefox），他的渲染都相似於第二行的樣子，可是在 Chrome 中，不人工加 space 就會致使這樣的問題。緩存

Well，這很爲難，若是是我的博客，固然能夠經過人工加空格的方式來控制，可是若是你作的是 UGC 相關（用戶社區）的內容，可能就要用別的方法去控制了。markdown

首先，當咱們發現別的瀏覽器正常，而 Chrome 不正常的時候，咱們已經習慣在 Chromium 的 issue list 裏挖掘信息了。app

固然，咱們成功挖掘出來了相似的信息 Issue 1083965: Regression: Emoji spacing too narrow in Mac OS 10.15 layout tests，可是你也能夠從相關連接中看到一些討論和解決方案，大體總結一下以後我想到的解法：oop

前端匹配，在 emoji 里加上 span，而後針對 Chrome 寫兼容性代碼，前端的變動衆所周知的是侵入性最小的，就算 Chrome 修復了也能夠無縫的刪除。
後端處理，依舊是匹配的思路，只是匹配後加上空格再存入庫，這樣渲染時就沒有額外的開銷了
不處理，Chrome 本身的 Bug 本身修

總結

你會發現 Chrome Bug 的解決思路就是——查 issue，看討論，罵一句辣雞 Chrome，而後再決定修仍是不修。spa

歡迎在個人博客看到更多更新：www.codesky.me/