首页 > 技术 > Firefox 当中HTML控件无法正常显示

Firefox 当中HTML控件无法正常显示

今天照常上网的时候,突然发现自己的Google主页上面的所有按钮上面的文字都消失了,所有的单选按钮也都消失了。
变成了这样:

Firefox Render HTML Control Bug

这个问题最后得以解决,解决方案如下:
首先,在地址栏输入about:config,然后找到nglayout.debug.enable_xbl_forms这个配置项,如果它是true的话,把它改成false。重新启动Firefox即可。

======我是无聊的分割线======

如果你的兴趣仅限于解决这个问题,下面的查错过程请无视。

这当然是非常不爽的一件事情,于是我开始回忆在上次显示尚且完好之后我做了什么操作,但是实在想不起来上次完好是什么时候的事情了——我上网一般都是在Google Reader上面徘徊,而Google Reader上面确实没有什么显眼的HTML标准控件可以让我发现这个问题。

于是没有办法,只好开始手动排错。在重新启动Firefox,重新启动Windows,用IE访问Google主页三步之后,基本可以排除系统原因或者Google的网页本身的原因。接下来看看是不是插件的问题,那么就先从“安全模式”开始看看问题是否能够解决。于是打开Firefox在开始菜单当中的安全模式,然后把“禁用所有扩展”打勾,重新访问Google,问题依旧,因此也不是插件的问题。那么是Firefox本身程序的问题么?为了考察这个,我新建一个Profile:在命令行中输入<path_to_firefox>\firefox.exe -P,注意P需要大写,然后再弹出对话框当中选择新建配置文件之类,完成之后用这个新的配置文件启动,然后访问Google,没有问题。因此看起来问题仍然在Profile本身。

Profile当中既然不是插件的问题,那么很可能就是首选项的问题了。我们知道在每个Profile目录下面有一个prefs.js的文件,是Firefox在当前情况下的所有的首选项的值,也就是在about:config里面看到的东西。最简单的就是比较两个Profile当中的prefs.js文件。在经过了大约半个小时,尝试过数十个不同的首选项之后,发现了nglayout.debug.enable_xbl_forms这个罪魁祸首。

然后用这个key的名字来搜索,发现其实这个是从Mozilla 1.3就开始有的问题,最早可以追溯到2002年12月:

XBL-based form controls are broken and
unusable in 1.3 and trunk builds.
(bug 185612)
If HTML form controls are not appearing and functioning on HTML pages,
check ‘prefs.js’ for the line ‘user_pref("nglayout.debug.enable_xbl_forms", true);’.
NOTE: this will only affect you if you had previously set this preference
in the ‘Debug’ panel in a previous build of mozilla. Casual users should
never change any of these settings.

这个至今未关的Bug (185612)就是在讨论我遇到的这个问题。

事情还没有结束。

在我没有修改这个键值的情况下,是谁动了我的Firefox键值?

在仔细回顾了这个问题之前一天我所做的事情之后,发现嫌疑最大的是插件 XPCOMViewer 版本0.9a。在新建的Profile上面尝试,发现一旦打开XPCOMViewer的主窗口,这个键立即就被改变成了true。也许是作者为了绕过某个难解的bug吧。之后查阅XPCOMViewer网站,发现作者公布的最新开发版1.0a当中已经修复了这个问题,也许我应该给作者发一封信告诉他应该更新一下Mozilla网站上面的版本了。

最后要澄清一下,虽然0.9a有这样的问题,但是作为一个仍然在sandbox当中的项目,这个扩展已经做得相当的好用。根据作者最近的一篇文章当中所说,1.0a版本支持一个非常cool的特性:直接将一个XPCOM组件导出成为Javascript/C++/Python的代码。对于有意在Firefox平台上面做点事情的朋友,这个扩展值得推荐。

标签: ,
  1. 本文目前尚无任何评论.
  1. 本文目前尚无任何 trackbacks 和 pingbacks.