目前参与的项目中有个弹窗音乐播放器,使用url传参(模拟get方法)实现无刷新为播放器(弹窗)添加歌曲列表的功能。偶尔会遇到歌曲列表被截断的情况。仔细研究后发现只有在首次弹窗时发生问题,如果传参时播放器窗口已打开,则无此问题。

刚开始以为是脚本加载或执行过程中依赖关系处理不当导致此问题,而窗口已打开由于加载缓存文件较快不存在网速影响。直到今天安插debug脚本结合调试工具才发现真正的问题在于通过url传递的参数超长部分被截断了,诡异之处在于:播放同样的歌曲列表,按理说传递的参数包括参数长度都是一样的,如果是浏览器限制导致问题,给同样的参数应该产生相同的结果才对,而实际操作中却只在首次播放(弹窗口)时出现参数被截断的问题。

唯一可能导致问题的差异变量是目标窗口(以window.name标识)的存在情况,通过window.open打开一个指定name参数的窗口,如果该窗口不存在,则传递的url参数(字符串)长度超过2083部分被舍弃;若目标窗口存在,则url参数长度超过4113部分被舍弃。

截图为证:

最后经证实,仅在IE下存在此差异,FF下首次和之后弹窗传参的长度并无差异。

IE最大URL长度2083的限制官方已有给出 (http://support.microsoft.com/kb/208427)而window.open可以让IE获取到长度达4113的url却是这次troubleshooting的意外收获。

最初认为是脚本加载导致问题的判断显然是错误的,错误的判断基于测试人员的描述和自身经验形成的思维定势;到后来亲手测试不同情况,找到产生问题的差异变量为线索;直至最后按图索骥,编写专门的调试函数,找到问题产生的根源并通过对比和量化来证实结论。

测试环境:ie8浏览器。

启示:

永远别试图摸透(老版本?)IE的怪癖行为;

不要被问题的诡异表象所迷惑,要弄清问题产生根源还得靠回归代码和调试工具。