今天为了实验一个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一直是一个“千疮百孔”的产品，恐怕会给前端开发者带来又一轮的灾难。