表面上没有任何有趣的地方。但仔细一看，会发现选区的颜色是浅蓝色，而不是默认蓝。第一直觉是是有什么特殊的 CSS 属性，立马 firebug:

不看不知道，一看真蹊跷。selection-highlight 是选区，选区下面是一张图片 page-image!
于是立刻发现一个非常牛逼的特性：Ctrl + C 可以复制图片中的文字！

google 太强悍了，好在前端代码都是开源的，下面简单分析下。

首先数据在哪呢，这个比较容易找到，在 firebug 里有一个请求返回的数据如下：

<?xml version="1.0" encoding="UTF-8"?>

<pdf2xml>
<meta name="Creator" content="Adobe Acrobat 8.1 Combine Files"/>
<meta name="Producer" content="Adobe Acrobat 8.1"/>
<meta name="CreationDate" content="20100316080708-04'00'"/>
<page t="0" l="0" w="612" h="773">
 <text l="188" t="754" w="237" h="11" p="188,24,214,15,232,37,271,
7,280,39,322,7,330,11,344,24,370,23,395,20,418,7">
Please post comments or corrections to the Author Online forum at</text>
...

有了这份数据，就可以根据选区得到对应的文本。

接下来的问题是，如何将文本放到剪贴板里？第一反应是用 flash 实现，但感觉 google 不会这么做。禁用掉 flash 插件后，功能正常，这说明是用 js 实现的。

通过 Profile 工具 + Fiddler + 肉眼识别 + 运气，终于定位到了关键代码：

n.am = function(a) {
    if (! (!this.k.Ca && Mr(this, a))) {
        ac && this.lf.focus();
        this.lf.select();
        Nr(this, a)
    }
};

只要注释掉上面的代码，Ctrl + C 复制功能就无效。focus 和 select 为我们提供了进一步线索，在 HTML 里，发现了秘密：

到此真相大白：当用户按下 Ctrl + C 时，js 会注入事件，首先根据坐标从数据里取出对应文本，然后将文本赋值给 textarea, 并将其激活和选中。这样，就和用户选中 textarea 的内容，再按下 Ctrl + C 的效果是一样了。

强悍的 google, 技术创新无处不在！

注意：利用 textarea 只能复制纯文本，如果想复制富文本，可以借鉴 google docs 编辑 Word 文档时的处理方式：采用 iframe 充当临时容器，有兴趣的可以进一步研究。

简单演示：goog-docs-copy-demo.html

发现这个秘密后，最近在疯狂搞编辑器的牛人承玉（欢迎搞编辑器的其他牛人加盟）立刻想到了各大站长们非常喜爱的功能：附带警告信息的禁止copy. 据说，能成功复制的，都不是“人”。

我的尝试是：点击按钮，复制指定文本到 Clipboard 里。应用场景是点击按钮复制证件号码等。尝试代码大家可以看上面 demo 页面源码中的注释。事件可以正常模拟并分发出去，但复制操作惨兮兮地失败了。感觉原因在于浏览器安全限制，对于触发的异步 Ctrl + C, 浏览器会限制其功能。

Google 的产品里有很多秘密，真诱人，创意无限！

用 Fiddler 监控，在 IE6 下，资源下载顺序为：

很明显，下载顺序从上到下，文档流中先出现的资源先下载。在 IE8, Safari, Chrome 等浏览器下也类似。

Firefox 对下载顺序做了优化：

Firefox 会将 js, css 提前下载，而将图片等资源延迟到后面下载。

对于渲染，利用 Fiddler 将网速调慢，可以看到 css 下载后会马上渲染到页面，渲染和下载同步进行。js 的解析和运行，也类似。

对于 js 运行，以及页面加载相关事件的触发，特别做了测试。在 Firefox 下，打开测试页面：

[22:13:32.947] HTML Start
[22:13:32.947] normal inline script run time
[22:13:34.904] normal external script run time
[22:13:35.775] [body] normal external script run time
[22:13:35.789] [body end] normal external script run time
[22:13:35.789] HTML End
[22:13:35.791] deferred inline script run time
[22:13:35.791] deferred external script run time
[22:13:35.793] DOMContentLoaded
[22:13:38.144] images[0] onload
[22:13:38.328] images[1] onload
[22:13:39.105] images[2] onload
[22:13:39.105] images[3] onload
[22:13:39.106] window.onload

很明显，JS 的运行严格按照文档流中的顺序进行。其中 deferred 的脚本会在最后运行（注：Firefox 3.5 开始支持 defer，而且支持得很完美）。

再来看下 IE8，结果如下：

[22:33:56.806] HTML Start
[22:33:56.826] normal inline script run time
[22:33:57.786] normal external script run time
[22:33:57.812] deferred inline script run time
[22:33:57.816] document.readyState = interactive
[22:33:57.934] [body] normal external script run time
[22:33:58.310] [body end] normal external script run time
[22:33:58.310] HTML End
[22:33:58.346] deferred external script run time
[22:33:58.346] images[0].readyState = loading
[22:33:58.346] images[0].readyState = complete
[22:33:58.346] images[0] onload
[22:33:58.361] doScroll
[22:33:58.451] images[1].readyState = loading
[22:33:58.479] images[1].readyState = complete
[22:33:58.479] images[1] onload
[22:33:58.794] images[2].readyState = loading
[22:33:58.854] images[2].readyState = complete
[22:33:58.854] images[2] onload
[22:33:58.876] images[3].readyState = loading
[22:33:58.876] images[3].readyState = complete
[22:33:58.876] images[3] onload
[22:33:58.887] document.readyState = complete
[22:33:58.888] window.onload

可以看出，IE8 下，defer 只对 external 脚本有效，对 inline 脚本无效。另，与 DOMContentLoaded 最接近的是 doScroll. 这是 doScroll 被广泛用来模拟 DOMContentLoaded 的原因。小心：仅仅是模拟，细节上并不等价。

还可以得到一个有点意外的结果：放在 body 结束前的脚本，执行时，依旧最好放在 domready 事件中。无论在 Firefox 还是 IE 下，解析到 HTML End 时，并不代表 DOM 可以安全操作，特别是页面比较复杂时。

从上面数据中，也可以看出 YSlow 性能优化法则里，建议将样式置顶和脚本置底的根据。

有兴趣的可以进一步测试动态添加样式和脚本的情形，会稍有不同，但没有特别 surprise.

最后总结下：

页面资源的下载顺序是从上到下的，文档流中先出现的资源先下载（注：存在并发，具体请参考 UA Profiler）。当某一样式下载完成时，会立刻渲染到页面（体现了层叠样式表中层叠在渲染时的含义）。当某一脚本下载完成时，也会立刻解析和运行。脚本的运行严格按照文档流中的顺序进行，deferred 的脚本会在正常脚本运行之后运行（Firefox 和 IE 下）。

特别需要留意：脚本运行时，会暂停该脚本之下所有资源的下载（因为脚本可能改变文档流，甚至跳转页面，浏览器的暂停策略是合理的）。要小心内联脚本，经常会阻塞后续下载。

好了，废话不多说。以上结果，建议各位亲自测试，反复测试，疯狂测试，一直到眼花缭乱稀里糊涂恍然大悟继续糊涂为止……

10. IE6下的背景闪烁bug

这个bug久闻其名，但我自己从来没遇到过。纳闷了许久，后来才发现，这是一个非典型性甚至可以忽略的bug. 因为它的触发条件离普通用户很远：

The cause of flickering is choosing “Every visit to page” in Tools » Internet Options… » Temporary Internet Files » Settings…

Selecting anything other than “Every visit to page” will fix all flickering. Fortunately, the means that the flicker problem plagues developers far more than your common user.

只有IE的缓存选项设置为“Every visit to page”时，才会触发。普通用户的默认设置是“Automatically”, 不会遇到此问题。因此继续往下阅读之前，请确保IE6的缓存设置为“Every visit to page”, 否则你将看不到神奇的现象。

测试：test_11.html

<style type="text/css">
    a { background: #f00 url(square.gif) }
</style>
<a href="#">test link</a>

上面的代码平淡无奇，但在IE6下，当鼠标划过test link时，背景会瞬间变红。如果你看不到此现象，请用老虎钳将网线剪掉一半，降低网速后再测试。

除了给链接A设置背景色，还有一些其它触发条件，详细资料请参阅：Minimize Flickering CSS Background Images in IE6.

注意：只有IE6下，设置“Every visit to page”, 并且给元素A设置了背景色等条件下，才会触发此bug. 上面引用的文章中提到三种解决办法：1. 调整服务器的配置，2. 双缓冲背景，3. js解决办法：

try {document.execCommand("BackgroundImageCache", false, true);}catch(e){};

到此，似乎已经尘埃落定。但是，好奇虽然害死猫，却也能发现猫世界里的更多秘密：

上图是用Fiddler监控鼠标在链接A上移进移出时的HTTP请求。虽然请求的结果是304（Not modified），但从发送请求到服务器返回304，依旧是需要时间的。在这个时间差里，链接A的背景是红色的，而不是图片。多余的HTTP请求才是背景闪烁的真正原因。

明白了这一点，可以看出“双缓冲背景”法，是治标不治本，是视觉上的小hack，并没有减少无谓的HTTP请求。采用调整服务器配置或execCommand hack，才能彻底杜绝多余的HTTP请求。

微软很委婉在一个hotfix中提到这个bug：Available memory decreases when you view a Web page in Internet Explorer 6 Service Pack 1. 当script中频繁改变一个设置了背景图的按钮的背景色时，会造成IE内存泄漏。微软的文档太文档了，Resolution那一段，我反复读了好几次，才明白微软要表达什么意思，囧。

鉴于目前很多公司的图片服务器配置里已经自动fix了此bug，以及IE6的逐步淡出，还有触发条件离普通用户较远，我们可以逐步忘掉此bug了，就像我们逐步淡忘掉ie 5.5的很多css hack一样。

休息一下，上面只是引子，精彩内容在下面。

11. 切换class时，背景图的请求

链接的hover状态切换, 是class切换一个特例。更一般性的测试如下：

<style type="text/css">
    .test1 { background: url(1.jpg) }
    .test2 { background: url(2.jpg) }
</style>
<div class="test1" id="J_Test">test</div>
<a href="#" id="J_Link">切换className</a>
<script type="text/javascript">
    document.getElementById('J_Link').onclick = function() {
        var el = document.getElementById('J_Test');
        el.className = (el.className == 'test1') ? 'test2' : 'test1';
        return true;
    };
</script>

测试：test_10.html

结论：当快速点击“切换className”时，除了IE，其它浏览器都只会产生两次请求。但在IE（包括IE8）中，用Fiddler能捕捉到如下请求：

带红色停止标志的，是Aborted Session. 也就是说，在IE下，当一张图片未下载完成时，如果class就已经切换，正在下载的图片会被中止掉。被中止掉的图片，下次用到时，会再次发送请求。直到图片成功下载后，切换class时才不会再次请求图片。

注意：如果你的观察结果和上面的结论有异，请检查 Internet Options… » Temporary Internet Files » Settings… 没有选中”Every visit to page”, 以及Fiddler中没有禁用Cache. 否则图片下载完成后，依旧会重新发送请求。如果观察不到请求，请清空IE缓存后再测试。另外，一定要记得用老虎钳剪掉一半网线。

可以看出，即便在IE8下，当网速较慢时，快速切换某个元素的class，依旧会造成闪烁。要一直到背景图片下载完成后，才不会闪烁。

知道了问题所在，解决办法就很容易想到了：采用Sprite技术，切换class时只改变background-position.
测试：test_10b.html
注意：用Sprite合成一张图片后，你点得再快，IE也始终只发送一个图片请求。

很想结束本文了，无奈IE下还有一个更诡异的闪烁现象… Come on~

12. 神秘的闪烁

直奔测试页面：test_12.html

第一行星星，当鼠标每次悬浮上去，都会产生一个图片请求：

原来老怀疑JS写法有问题，琢磨了许久，才注意到上图中Caching栏的值：public Expires: Sat, May 2009 04:59:57 GMT. 超级汗googlepages的设置。

再来看第二行星星，悬浮时，没有第一行星星的问题。从Fiddler中可以看出，第二行星星的背景文件也是过期的，为什么却不重新下载呢？

相信你已经留意到测试页面左下角那颗孤零零的星星，这就是第二行星星正常的救星。

根据上面的现象，我们可以猜测IE请求图片的虚拟过程为：

1. 需求：改变classA, 需要背景图imgA.
2. 在页面中寻找是否已经有元素使用imgA, 有的话，直接共用。
3. 在缓存中找到了imgA，判断Expire头，如果过期了，则重新发送请求，全新下载。
4. 如果Expire头没过期，直接复用。
5. 在缓存中没找到，发送请求，从服务上下载。

其中第3点，IE的处理方式比其它浏览器严格，其它浏览器在刚才的测试页面中，不会重新下载。

另外，前面已经总结过，当切换到classA，开始下载imgA后，当classA又没用了时，IE会中断imgA的下载，而其它浏览器则会一直下载完。从逻辑上讲，IE的处理方式很严谨。但实际体验上，IE的处理方法很恼火。好与坏，有时真难评说。

后记

上面的结论，都仅仅是“定律”，建立在黑盒测试的基础上。可能会有不少错误之处，如果发现了，还望各位能及时反馈给我。

1. 隐藏图片

<img src="1.jpg" style="display: none" />

测试：test_1.html
结论：只有Opera不产生请求。
注意：用visibility: hidden隐藏图片时，在Opera下也会产生请求。

2. 重复图片

<img src="1.jpg" />
<img src="1.jpg" />

测试：test_2.html
结论：所有浏览器都只产生一次请求。

3. 重复背景

<style type="text/css">
    .test1 { background: url(1.jpg) }
    .test2 { background: url(1.jpg) }
</style>
<div class="test1">test1</div>
<div class="test2">test2</div>

测试：test_3.html
结论：所有浏览器都只产生一次请求。

4. 不存在的元素的背景

<style type="text/css">
    .test1 { background: url(1.jpg) }
    .test2 { background: url(2.jpg) } /* 页面中没有class为test2的元素 */
</style>
<div class="test1">test1</div>

测试：test_4.html
结论：背景仅在应用的元素在页面中存在时，才会产生请求。这对CSS框架来说，很有意义。

5. 隐藏元素的背景

<style type="text/css">
    .test1 { background: url(1.jpg); display: none; }
    .test2 { background: url(2.jpg); visibility: hidden; }
</style>
<div class="test1">test1</div>

测试：test_5.html
结论：Opera和Firefox对于用display: none隐藏的元素背景，不会产生HTTP请求。仅当这些元素非display: none时，才会请求背景图片。

6. 多重背景

<style type="text/css">
    .test1 { background: url(1.jpg); }
    .test1 { background: url(2.jpg); }
</style>
<div class="test1">test1</div>

测试：test_6.html
结论：除了基于webkit渲染引擎的Safari和Chrome，其它浏览器只会请求一张背景图。
注意：webkit引擎浏览器对背景图都请求，是因为支持CSS3中的多背景图。

7. hover的背景加载

<style type="text/css">
    a.test1 { background: url(1.jpg); }
    a.test1:hover { background: url(2.jpg); }
</style>
<a href="#" class="test1">test1</a>

测试：test_7.html
结论：触发hover时，才会请求hover状态下的背景。这会造成闪烁，因此经常放在同一张背景图里通过翻转来实现。
注意：在图片no-cache的情况下，IE每次hover状态改变时，都会产生一次新请求。很糟糕。
2009-05-13晚补充：上面的解释有误，更详细的解释请参考续篇。翻转技巧指的是Sprite技术，例子：test_7b.html, 在ie6下不会产生闪烁。

8. JS里innerHTML中的图片

<script type="text/javascript">
    var el = document.createElement('div');
    el.innerHTML = '<img src="1.jpg" />';
    //document.body.appendChild(el);
</script>

测试：test_8.html
结论：只有Opera不会马上请求图片。
注意：当添加到DOM树上时，Opera才会发送请求。

9. 图片预加载

最常用的是JS方案：

<script type="text/javascript">
    new Image().src = '1.jpg';
    new Image().src = '2.jpg';
</script>

在无JS支持的环境下，可以采用隐藏元素来预加载：

<img src="1.jpg" style="visibility: hidden; height: 0; width: 0" />

测试：test_9.html

终于到总结了

1. 对于隐藏图片和隐藏元素的背景，Opera不会产生请求。
2. 对于隐藏元素的背景，Firefox也不会产生请求。
3. 对于尚未插入DOM树的img元素，Opera不会产生请求。
4. 基于webkit引擎的Safari和Chrome，支持多背景图。
5. 其它情景，所有主流浏览器保持一致。

对图片请求的处理上，个人觉得Opera走在前列。

番外

1. 用Fiddler监控Opera时，如果是本地服务器，需要在Opera的代理服务器设置里，将本地服务器勾选上。

2. 查看HTTP请求数，还有一个万无一失的方法是，直接查看Apache的access.log文件。

3. 我的Firefox对于重复图片和重复背景，会产生重复请求。禁用了所有扩展，问题依旧。有知详情者，还望告知。

直觉反应是表头的CSS有问题，仔细检查后，却没发现问题。难道是JS引起的？禁用JS后，问题依旧。

开始怀疑是页面中某段HTML代码导致了这个bug. 前几天刚用熟了Fiddler，于是毫不犹豫地立马派上战场：

其中E:IdeaProjectsTaobaoTest.html是保存的页面源码，也可以用bpu或Unlock for Editing等方式直接在Fiddler的SyntaxView中修改。但对于频繁修改来说，用AutoResponder映射到本地，再用自己喜欢的编辑器修改会更方便。

凭着经验，逐步移除Test.html中的代码块，直到只剩下表格本身，结果发现问题依旧。此时已经耗费了10多分钟，看着ie7下狰狞的空白，着实有点沮丧。

于是习惯性地打开google，琢磨了几个关键词，结果却没有搜到任何相关话题。

仔细回想这个页面的开发过程，demo在ie下是没问题的。后台套vm模板时，我也曾仔细检查过。难道最近又有啥修改让HTML代码出问题了？立刻打开Firefox的HTML Validator插件：

一堆警告触目惊心，开发居然在两个tr之间放了两个input元素。立刻将input移动到td里面，刷新页面，bug消失了！

马上通知开发修改vm模板，至此已经耗费了近一个小时，庆幸的是一切搞定！

总的来说，这次bug排查效率还比较高。但现在回过头来想想，发现自己还是犯了不少“错误”：

1. 当直觉解决不了问题，对bug毫无头绪时，应该首先用HTML Validator检查，不少诡异bug都源自代码的不规范。比如上面的bug，如果排查时遵守这一条，应该10分钟内就能搞定。
2. 对于这个bug，其实根本用不着Fiddler. 完全可以保存页面到本地，直接调试本地文件即可，Fiddler仅满足了技术欲望。对于复杂环境下的JS bug，才是Fiddler的真正用武之地。目前我自己以及不少同事都有点滥用Fiddler（感觉上很酷），以后还是要选择性使用，Fiddler未必是最高效的。

对于bug排查，小马曾有过一个很好的总结：1. 善用工具，2. 善用搜索。无他，唯手熟尔！

我补充一点：3. 勤于总结。让知识和经验分享沉淀下来，为了自己的成长，也是为了前端整个行业的成熟。

1. 使用AutoResponder本地调试文件。请参考如何直接调试线上页面的JavaScript和CSS.
2. 使用QuickExecBox快速操作。请参考QuickExec Reference. 推荐熟练掌握的命令：?sometext, bpu, go, urlreplace. 快捷键：Alt + Q, Ctrl + I, Shift + Del, Ctrl + X, F6.
3. 使用Filter过滤信息。比如禁用JS, 设置断点等等。
4. 使用bpu + Inspectors动态修改Response. 比如修改页面中的JS代码片段等等，非常有用。
5. 使用Request Buidler测试请求。可以很方便的测试ajax代码。
6. 使用Statistics + Timeline + neXpert查看性能等统计数据。
7. 使用CustomRules, 自定义配置和命令等。比如修改var m_DisableCaching: boolean = false;的值为true, 就可以默认禁止缓存。还可以自定义命令等等。
8. 开发自己的扩展。请参考Extending Fiddler with .NET Code.

最后强烈推荐Fiddler的视频教程：Fiddler Demonstration Videos（听不懂没关系，能看懂就能学会）

另外，Firefox下推荐使用FoxyProxy自动切换代理。一次设定，服务终身。

HTML Validator

http://users.skynet.be/mgueury/mozilla/

很喜欢这个扩展的Tidy算法模式，可以检查出HTML页面中绝大部分嵌套和书写错误，并且针对每个错误都有详细的说明和推荐写法。当然，很多时候，我们不大可能去纠正所有错误和警告。一个常用的小技巧是：将可以容忍的错误添加到Hidden列表中。这样，只要看看右下角的状态信息，就知道页面中是否还有错误了。

Launchy

https://addons.mozilla.org/en-US/firefox/addon/81

这个扩展相见恨晚，一见就再也离不开了。如上图所示，能很方便的让我们在不同浏览器中加载测试页面，还可以配置编辑器。注意的是：默认情况下，Launchy会自动探测浏览器和编辑器，我的习惯是将自动探测关闭，按照选项里的说明，在chrome目录下通过launchy.xml手动指定菜单项。这是我的配置文件：Firefoxprofilechromelaunchy.xml. 目前IETester只能打开，不知道怎么传送参数过去，还希望知道的指点一下。（IETester 0.3已经支持Command line arguments）

Fiddler Switch

https://addons.mozilla.org/en-US/firefox/addon/9373

在前端开发界，有这么一个说法：Firefox + Firebug + Fiddler，称之为 3F，拯救了前端的工作。Fiddler是个伟大的工具，默认在IE上工作得挺好，但在Firefox上需要设置代理，有点麻烦，Fiddler Switch就是Taobao UED空帷达人为了解决此问题而开发的。如果你还没用过Fiddler，推荐阅读下这篇文章：如何直接调试线上页面的JavaScript和CSS。

Johnny Cache

https://addons.mozilla.org/en-US/firefox/addon/3817

是否厌倦了 Ctrl + F5? 是否有时忘了切换 Web Developer Toolbar 禁用的Cache，而导致上网很慢？Johnny Cache让你一次配置，永久解决烦恼。我很喜欢这种谦虚却非常实用的扩展。

Firefox DNS Flusher

https://addons.mozilla.org/en-US/firefox/addon/7408

这也是一款非常谦虚但绝对实用的扩展。开发测试时，经常要修改hosts文件。但默认情况下，Firefox会缓存DNS，修改hosts文件后，有时得重启Firefox才能生效，这是很让人恼火的。装了这个扩展，就再也不用等待漫长的重启了。同时，还拥有了一个附加功能：直接查看域名的ip.

MeasureIt

https://addons.mozilla.org/en-US/firefox/addon/539

根据mockup制作精确的demo是前端工程师们的日常工作，通常的做法是在Photoshop或其它图像处理软件中测量，但来回切换窗口是有点影响效率的。MeasureIt能让你直接在页面中的测量，方便快捷。

我的Firefox上，除了Firebug, 开发用的扩展就上面这些了。除了MeasureIt用的频率不是很多，其它扩展几乎天天都用。感谢这些扩展，让我有更多的时间好好生活。

上面的方法，对于简单页面，是够用的。但是对于稍微复杂的页面，IE的另存为经常不保真，如果页面中涉及Ajax等bugs，保存到本地更是难以调试。这时有个很自然的做法是，将开发环境Run起来，当时怎么开发的，现在就怎么调试。这样做肯定能解决问题，但要调动很多资源，后台开发工程师、前台开发工程师等等都要参与。对于小团队来说，也许是可行的，对于大团队来说，如此大动干戈，除非到了最后，是不会这样做的。那我们应该怎么做呢？先来看一个工具：

Web开发中有个大名鼎鼎的工具：Fiddler. Fiddler是一个http调试代理，它能够记录你电脑和互联网之间的所有http通讯。Fiddler可以让你检查所有的http通讯，设置断点，以及Fiddle（Fiddle的英文意思是胡乱修改，很幽默的表达Fiddler的用途）所有“进出”的数据（指cookie,html,js,css等数据）。

嘿嘿，是否从上面的介绍中嗅探到了某种解决方案？Fiddler可以让我们Fiddle所有”进出“的数据！我们要调试线上页面的bugs时，可以先分析是什么文件引起的，找出这些嫌疑文件，下载到本地，然后利用Fiddler将线上的请求Fiddle到本地的对应文件。这样我们就可以随心所欲的修改这些嫌疑文件了，直接刷新线上的页面就可以看到效果，烦人的环境问题根本就不用考虑，而且一切都是高保真的。

上面说的是思路，下面我会举个例子来说明。

举例子之前，请先安装Fiddler（怎么下载安装就不多了，一路Next）。安装好后，在IE的工具条上会出现Fiddler2图标，点击启动Fiddler. 启动后，通过IE访问任何网站时，所有http进出数据都会在Fiddler上显示出来。但是等等，怎么老说IE呢？虽然在IE上能通过IE Developer Toolbar和Companion.JS来调试CSS和JS，但被firebug宠坏了的我们，总期望着Firefox上能搞定的问题绝不通过IE去调试。为了我们的美好期望，根据Fiddler的官方说明，我们只要简单的进行以下操作即可：

首先，找到BrowserPAC.js这个文件，默认放在

• c:Documents and SettingsYour NameMy DocumentsFiddler2ScriptsBrowserPAC.js

Vista下在User的对等目录里。

接着，打开亲爱的Firefox3，Tools – Options – Advanced – Network:

点击Settings…:

选中自动代理配置URL，将BrowserPAC.js的绝对路径复制过去，确定。如果想让Fiddler监听其他浏览器，同上设置即可。

至此准备工作完毕，我们进入正题（才进入正题？各位看官稍安毋躁，喝杯茶，养养神，再接着往下看）。

在我的淘宝 – 已卖出的宝贝页面，有个修改价格的功能：

前些天发现一个bug，当点击修改价格按钮之后，主页面上的价格没有更新。

初步分析后，觉得以下js文件有问题：

• http://assets.taobaocdn.com/js/app/trade/trade.js
• http://assets.taobaocdn.com/js/app/trade/trade_business.js

因为涉及Ajax调用，保存为HTML本地调试不了。这时想起Fiddler，问题迎刃而解。

首先将上面两个文件下载到本地，启动Fiddler，在AutoResponder栏添加替换规则：

如上图添加两条规则后，在Firefox中刷新页面，上面两个js文件就从本地获取了，嘿嘿。接下来，用喜欢的文本编辑器加Firebug尽情的调试吧，就像当初开发时一样。等把bugs解决了，压缩并上传相应的js文件，并通知后台开发者修改vm中js文件的时间戳，然后等着发布就行。

CSS也是一样的调试，不赘述。在IE、Safari、Opera中的的使用方法类似，不多说。

希望本文能对你有所帮助。