如何从一个 Chrome 的 Bug 中找到解决方案

1,124 阅读3分钟

在前端开发,或者说 Web 开发中,我们会经常遇到,在某个浏览器遇到了问题,但是别的浏览器没有,过去,我们考虑的可能是 IE6 的兼容性,而在 Chrome 一骑绝尘的今天,Chrome 而其他浏览器没有的问题反而成为了更大的问题。

在此之前遇到过几个 Chrome Bug,我会以两个 Chrome Bug 为例说说实际是怎么解决的:

在请求提交时无限 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 相关(用户社区)的内容,可能就要用别的方法去控制了。

首先,当我们发现别的浏览器正常,而 Chrome 不正常的时候,我们已经习惯在 Chromium 的 issue list 里挖掘信息了。

当然,我们成功挖掘出来了类似的信息 Issue 1083965: Regression: Emoji spacing too narrow in Mac OS 10.15 layout tests,但是你也可以从相关链接中看到一些讨论和解决方案,大致总结一下之后我想到的解法:

  1. 前端匹配,在 emoji 里加上 span,然后针对 Chrome 写兼容性代码,前端的变更众所周知的是侵入性最小的,就算 Chrome 修复了也可以无缝的删除。
  2. 后端处理,依旧是匹配的思路,只是匹配后加上空格再存入库,这样渲染时就没有额外的开销了
  3. 不处理,Chrome 自己的 Bug 自己修

总结

你会发现 Chrome Bug 的解决思路就是——查 issue,看讨论,骂一句辣鸡 Chrome,然后再决定修还是不修。

欢迎在我的博客看到更多更新:www.codesky.me/