如何从一个 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/