今天又被chrome给伤了

本文摘自 勾三股四 更早时期的 不老歌 博客。

今天为了实验一个file api的效果,不得不放弃mac下自带的safari浏览器,装上了chrome——在这之前我觉得safari应该足够了,因为从开发者的角度看,我一直觉得chrome在内核方面的改造步伐过于激进,而safari相对稳妥一些,不过file api,这个东东safari确实没有支持,很纠结。在深思熟虑之后,还是决定把chrome装上了。

结果初次试用 chrome for mac 非常沮丧,再一次以无尽的崩溃为代价在尝试着新技术。具体问题是这样的:

我想实现的效果,是拖拽一个图片到页面上指定的矩形区域,然后把这个图片作为背景显示出来。这分为了两步:第一步,用ondrop捕获外部图片文件拖入的事件;第二步,可以从该事件的event.target.result中获取图片的base64编码,然后把这段编码赋值给background-image属性,格式为url(...)即可。

网上有一个现成的例子:http://html5demos.com/file-api,其实我做的效果跟这个大同小异。

这件事情chrome for mac完成的很好,但接下来,我想把这个程序稍作改进,就遇到了问题

由于被拖拽进去的文件不见得是图片文件,这导致有些情况下,文件拖进去了,却无法正常显示成图片,我想加入一个智能判断的环节,如果图片生成失败,就进行提示。其实现成的方案是存在的,就是先把base64编码赋值给一个img标签的src属性,然后分别通过捕获这个img标签的onload和onerror事件来判断图片是否可以正常显示。

这样我的实现方案就变成了3个步骤,4段代码:

* 第一步,用ondrop捕获外部图片文件拖入的事件,和刚开始一样;
* 第二步,可以从该事件的event.target.result中获取图片的base64编码,然后把这段编码赋值给一个img标签的src属性,监听onload和onerror事件;
* 第三步,如果onload事件触发,则再把这段base64编码赋值给background-image属性;而如果on error事件触发,则提示图片生成失败。

把代码写好以后,刷新网页,把图片文件再次拖入定义好的矩形区域,这时chrome for mac就崩溃了……

问题基本定位在了img标签在onload中再次处理这段base64编码的时候,更具体的原因就不得而知了。无奈之下,我只好把这个新加入的功能又去掉。

这件事情就算这样过去了,但是我更觉得chrome越来越不靠谱了,除了这次的问题,我之前还遇到过或亲眼目睹周围的开发者遭遇web socket协议更改导致之前写好的程序不能工作、Audio内存管理不善导致播放大量音频时内存不能释放直至崩溃等等——更何况我这次安装的不是beta版也不是dev版,而是面向大众的正式版。如果未来的chrome一直是一个“千疮百孔”的产品,恐怕会给前端开发者带来又一轮的灾难。

向本文提出修改或勘误建议