IE6 启用代理自动配置 (PAC) 后的一个必现 Bug

最近从用户那里收到反馈说访问产品出现“白屏”,
由于版本上线前都必须在众多不同环境下通过测试,
于是猜想这个问题的出现与用户的浏览器设置有关;
进而联系用户来模拟其使用环境加以调试,
终于定位并解决了这个“非主流” Bug ,
记录如下以供各位参考。

这里先描述一下重现场景
必须同时满足如下所有条件:

  • IE 6;
  • 启用了“代理自动配置 PAC “;
  • 页面内容非空且使用 http 协议访问;
  • 页面引用了一个未经缓存的外部脚本;
  • 该脚本问了 location 对象;

该场景下访问页面会得到 Access Denied 错误(捕获错误后如下图),
出错位置正是访问 location 对象的那一句。

访问 location 对象时报错

测试环境只对 IE 6 启用了 PAC 而已,
其它设置均保持默认值,
所以除了说服用户升级浏览器或放弃使用 PAC 之外,
我们只能想办法去规避这个问题。

- 阅读剩余部分 -

[UserScript] 将 Web 离线迅雷注册为磁力、电驴等特殊链的处理程序

介绍

Web 离线迅雷打开 ed2k 链接

不知标题是否写得太绕口,
简单地说就是将离线迅雷注册为某些特殊(伪)协议的默认处理程序,
包括迅雷快车旋风磁力电驴

08 年写过一个Firefox 扩展来做“解码”这件事,
现在有了 Web 离线迅雷 Web 离线旋风等吸血利器
我在 OSX 上连 P2P 软件都懒得装了。 😱

于是去年干脆写了段脚本做了标题所述之事,
当时还顺手写了个油猴脚本
但一直存在间歇性登录态丢失问题,
于是就搁置了一年未发;
最近研究迅雷联盟时偶有所得,
貌似可以解决上述问题,
于是趁今天有空更新了一下发布出来。

原理简单就不多着墨了,
请自行去阅读 navigator.registerProtocolHandler 的文档

至于兼容性,
脚本虽是为 Firefox 的 GreaseMonkey 所写,
但所有遵循 UserScript 规范的脚本管理器都可以使用;
Chrome 当然能用,
但貌似它对自定义协议有前缀限制;
而 Opera 则未经测试。

2012.03.24 更新:
虽然 UserScript 本身(作为一种事实规范)在各种浏览器上都有其实现,
但完全开放 navigator.registerProtocolHandler 接口的浏览器并不多。
目前本脚本只在 Firefox 上测试通过。

使用方法

  1. 安装并启用该脚本;
  2. 访问 离线迅雷, 请确认当前你处于未登录状态;
  3. 浏览器将会提示你是否授权将离线迅雷注册为上述(伪)协议的默认处理程序(如下图);
  4. 禁用(或干脆删除)本脚本,开始使用吧。

Firefox 询问你是否将 Web 离线迅雷注册为磁力链默认处理程序

历史

  • 2011.02.24 1.0: 初始发布
  • 2012.03.06 1.1: 解决登录问题,增加使用说明

下载

webThunderHelper.user.js

浏览器的特征探测

【2010.12.08 更新】
抱歉,
用原生 IE9 测试后发现 IE9 的判断代码已失效,
研究将继续……

【2010.11.29 更新】
之前的 IE8 检测方式容易被“伪造”,
改为检查 Image 对象是否存在 prototype 的方式。(via)
另外有朋友说 IE8 的探测在 IE7 模式下也通过,
我想说这是我有意为之:
目的就是要探测浏览器本身的真实版本,
具体运行于哪种模式可以通过 doc.documentMode 来获得。

【2010.11.17 更新】
IE9 不知从哪个 Pre 版开始,
又恢复了之前更新时所提到的
非空数组字面量的最后一个元素缺失的问题,
也就是说这个 Bug 又得以“重现”了。
我个人推断是太多线上应用依靠这个 Bug 来识别 IE ,
因此开发团队不得已而为之。
但不管怎样,
本文还得继续。
目前利用了 IE9- 里 toFixed 方法在特定情况不会四舍五入的 Bug 来判定,
具体代码请见正文。


【2010.08.13 更新】
增强了 IE6 的区分能力。
当然更可以使用 IE 自己的条件编译,
只是有的压缩器支持度有限,
不便于日常开发。

【2010.04.18 更新】
更加严格地区分出了 IE 9,
增强了 Opera 的区分能力,
并将 Chrome 的判别特征换成了引擎特性 [via],
这样你就能看出国内哪些浏览器是从 Chrome 的内核改过来的了,
大家可以动手试试。 :)

【2010.04.17 更新】
IE 9 在我看来改进非常大:
有我所关心的对 Mutation Events 的支持,
还有事件模型的 W3C 化等等……
本文中我就不多冗述,
有机会再另文探讨。
由于在项目中大量使用特征判断,
IE 9 在这方面最显著的变化是:
之前那则“最短的 IE 判断法”已经失效,
一起被修复的还有一直伴随 IE 的数组 Bug:
非空数组字面量的最后一个元素缺失的问题(即:[null,]),
因此现如今的最短记录保持者(6字节的 !-[1,])也已然失效。(而且不支持 CC 压缩)
你也不要尝试使用 addEventListener 方法来判别,
因为 IE 9 已经支持了。(事件的改进非常大,这很好)
所以说 IE 已经越来越靠近标准,
如果在项目中有对 IE 进行特殊处理的代码,
你可能需要在 IE9下重新检查一下了。

由于我个人依旧是 XP 的忠实拥趸,
而 XP 又很悲剧地无法安装 IE 9,
所以一些测试是在 Haitao Jia 同学的协助下完成,
在此表示感谢。
也正因为如此,
我没有进行覆盖面太广的测试。
不过目前所发现的唯一“幸存”下来的 IE 系列 Bug 依旧与刚提到的数组 Bug 有关,
微软修复了字面量里的 Bug 却忘了当字符串被 split 成数组后却涛声依旧啊。
虽然判断起来稍微麻烦了点,
但不管怎样这是我目前发现的仅剩不多地可以用来判断 IE 全系列的代码:

- 阅读剩余部分 -

利用 CSS 跨浏览器地隐藏文字一法。

页面里使用 inline-block 元素时经常需要隐藏其文字,
比较流行的方法是将 line-height 的值设置得很大,
然后配合 overflow: hidden 来隐藏文字。
请容许我主观臆断地认为过大的行高会影响渲染效率,
而行高不够又可能在用户对页面进行放大操作时露出“马脚”(即未能被隐藏的部分)。
是否当 line-height:0 时对 Webkit 内核就没有办法了?
我想到利用透明文字来解决这一兼容问题,
并最终整理如下:

font-size:0; /* for firefox & opera */
color: transparent; /* for webkit */
line-height:0;
overflow:hidden; /* for IE */


自测后兼容的浏览器如下:

IE 6-8
Firefox 1-4
Opera 9-10
Safari 3-5
Chrome 1-6

如遇不兼容的情况可以留言。

当然隐藏文字的方法还有很多。
有人说“直接不填文字不就好啦”,
呃……
算我没说,
不过目前公司的产品对盲人阅读器的兼容还是有要求的。

YUI 全系列 Dom/Node 组件 getXY 方法的一个 Bug

因工作关系我已有些时日没用 YUI 写代码了,
这次由于项目需要我阅读了一些脚本库的代码,
无意间发现了这个 YUI 里 (Dom || Node).getXY() 的小 Bug。
查看了手边的 YUI 2 和 3 的多个版本代码,
均存在此问题。(怀疑其影响全系列)
时间不多,
抽睡前的一点时间写下来吧。

问题描述如下:
当浏览器不支持 node.getBoundingClientRect() 方法时,
我们会选择通过 offset 系列属性一层层向上计算偏移值,
最后得到一个“可能有错误的”元素坐标。
要修正这个错误,
我们需要沿着节点树一层层向上判断是否某个祖先“出现”了滚动条,
如果有,对不起,阉了。

大体的思路是这样没错,
YUI 也确实这样处理了,
而且它也知道元素定位方式中还有一种游离于布局之外的 fixed,
只可惜它没在碰到 fixed 元素时及时刹车,
结果就是在一种较特殊的布局下会多删一次滚动条高/宽度,
导致坐标计算错误。
可叹可叹,
它曾那么接近幸福。

所以当某个有滚动条的页面里存在一个 fixed 定位的元素,
而你又要用 YUI 去取该元素所包含的某个子元素的坐标时,
Bug 就出现了。
文字描述显然不够直观,
请猛击如下链接来查看不才基于 YUI2YUI3 所构建的示例。
(由于该 Bug 只影响不支持 node.getBoundingClientRect() 的浏览器,
请选用诸如 Firefox 2 / Chrome 1 / Safari 3 等浏览器来打开示例,
顺便在这里感谢 IE 团队为我们贡献了如此好用的一个方法)

- 阅读剩余部分 -