用了Firefox也有一段时间了，当它还叫做Firebird的时候我就已经好奇的装上了它。那个时候除了IE以外我还装了Mozilla(Suite)，真正是个庞然大物，后续版本经常建议在系统启动时运行它那个QuickLaunch，以便在用户真正需要浏览器的时候确保Mozilla(Suite)的一些组件已经装载了，否则那启动时间真是无与伦比，无论是想简单的用Mozilla Chat上个IRC还是用浏览器开它十几个tab。
貌似跑题了……
昨天闲来无事，焚香静坐后学习了一下Firefox的扩展机制，嗯，扩展，extension，而不是可能被一些人说为插件（plugin）的东西，我记得我以前好像唠叨过二者的不同，plugin应该更底层一些。看来我一直的理解还是有问题，在我的想法里Firefox作为浏览器来说还是一个真刀真枪的本地代码拼装起来的东西，那些UI控件还是用的操作系统的那套，只不过人家用了一些招数把跨平台的部分用代码封装起来，看上去比较类似wxWidgets、Qt之类的库，只不过全面一些，但其实上Firefox的方法来的更为颠覆一些，那就是浏览器上能看到的一切皆是XUL。
打开Firefox，映入眼帘的这个可爱的界面，无论你应用了什么外观主题，堆砌了多少扩展，它都是一个XUL文档（chrome://browser/content/browser.xul），查看$FIREFOX_DIR/chrome/browser.jar!/content/browser/browser.xul，这就是每天你面对着的这个界面，哦，它当然不包括Google Toolbar，没有AdBlock，这些都是通过扩展完成的，而不用直接修改这个XUL文档的内容。Firefox使用的XUL Overlay正是扩展和主题得以完成的根本，使用过程中感觉XUL Overlay很直观，无论是当作Overlay的XUL文档还是被Overlay的XUL文档，与普通的XUL文档都没有任何区别，除了一个描述清单（chrome.manifest）以外没有再多的废话，想改变哪里，就在Overlay XUL文档里描述你的界面你的想法，再向chrome.manifest里添加一行描述Overlay关系的指令（或许有其他方法描述？直觉那些RDF很不简单），然后把这些东西打包当作扩展安装，重启Firefox之后就能看到改变。用XUL的好处是任何人不用依赖任何开发工具就能很好的制作扩展，如果像我一直以为的那种依赖本地代码的应用的话，那就只有拥有熟练开发本领的专业人员才能制作扩展，或者像Maxthon一样依赖HTML，但HTML终究能力有限，其要解决的问题是显示，而不是要制造一套完整的UI解决方案，即使也可以像XUL一样使用javascript，但诸如command、commandset甚至数据源之类的高级货还是缺乏的，而且，虽然利用HTML也可以描出XUL中的所有控件，但模型上还是稍微有些差距，比如命令和事件以及数据源，好在经过Ajax的一阵吹风，HTML+Javascript也重新焕发光彩，用Dojo这样比较完善的东西来实现XUL也不是没有可能，然而还是那句话，模型上的差距，是HTML没法追上的，相反的在表现方式上XUL和HTML一样也有差距不是~
收获就是做了一个简单的扩展，用来在浏览flickr上的图片时直接访问原始图片:P 还有就是意外的发现了为什么Firefox有的时候可能让人觉得反应迟缓：阅读Firefox自己的chrome里的Javascript代码的时候，发现了很多调用setTimeout来延迟某些方法调用的地方，这些地方大部分是为了确保诸如文档（包括HTML以及XUL）加载、更新全局变量的完成，避免出现意外，比如在文档没有加载的时候去访问文档的属性及其内部变量，或者在全局变量上发生同步错误，导致一些灵异现象。我试了试直接调用被延迟调用的方法，其实这些方法的速度还是很快的。
可能做页面做多了，Greasemonkey的user scripts也做多了，在编写扩展中的javascript的时候总是搞混document对象，因为我还是试图用自己熟悉的方法，通过HTMLDocument来调用已经用烂了的那些方法，后来自己抽自己一下，提醒自己一定要用XUL文档里的元素提供的方法。
这几年真是白用Firefox了，竟然才知道Firefox究竟是个什么东西。用XULRunner（GRE）外加全套XUL、XPCOM来做浏览器的做法实在够cool，给我的感觉像是以UI驱动的Java=) Sigh，我还一直奇怪那么多号称基于”Firefox、Mozilla架构”的应用是怎么做出来的了，实在是老土的不行了……
Technorati : firefox
Recent Comments