IE下ul li 互相嵌套时候的bug,排查,解决过程及心得
2012-11-05 22:07
369 查看
昨天到今天上午都在查一个IE的bug,情形如下:通过异步请求获取json数据,然后拼接成html代码,最后使用innerHTML类似方法插入到文档流中。在chrome下和IE8\9下均表现正常。结果已进入IE7,浏览器就崩溃,更别提IE6了,也是一副死给你看的样子。于是我就把这个bug定位于IE6\7,其实这时候我已经陷入了这个固定思维模式中,浪费了不少时间。
检查bug的步骤
1. bug定位
在js脚本中,按照脚本执行的顺序,你可以用console或alert,来确定bug发生的代码区间,然后在区间内进一步来查找bug发生的具体代码段。
2. bug fix
通过排除,就是在插入节点内容的时候导致了bug,我用的是kissy的DOM.html()方法,其功能类似于DOM元素节点innerHTML方法,我起初认为是这个方法导致的IE6\7渲染出错,然后我换成了innerHTML方法,结果还是有误。
这时候我想到了内存泄露,看看是不是在循环拼接字符串的过程中,有循环引用或者其他原因造成内存泄露,然后在一些方法结束的时候,我把一些变量赋值null,来防止内存泄露(虽然不知道是否有效,但是至少我这么尝试过了),结果还是不行。
是不是数据过多,导致一下子渲染的时候崩溃呢?于是我减少了拼接的数据长度,这个起效了。1~3条数据的时候,可以渲染上,那就说明方法是没有错的;但是3条以上的数据,IE6\7还是无法响应。于是我又试着一条一条数据取持续插入,因为一次插入1条数据没有问题的话,我大不了多插入几次吧,但是IE还是有问题。其实,这时候我的思路已经偏离了。
后来找同事来看看,说之前也碰到过这个问题,是IE6\7下,标签没有正确闭合的原因导致的。没错,这就是这个bug的真正原因啦。后来,我把拼接的字符串打印出来,然后再使用格式化工具进行格式化,变很快发现了我拼接字符串的时候出现的这个问题,于是很快fix掉这个bug。我用的在线格式化工具:http://tool.chinaz.com/Tools/JsFormat.aspx
3. 测试
测试时候,我们写上一串html代码,并对一些标签不闭合,看看IE和chrome对比情况。
代码如下,在第二个li标签里,我们对ul标签中的其中一个<span>标签,做不闭合处理
IE 和chrome下都正常显示,如上图。
接下来通过开发工具调试看看。
在IE7~9下面,dom结构错乱,发送错误的地方就在那个没有闭合的<span>标签那里,原来的第三个<li>节点的内容直接插到了<span>节点下面。
我们再来看看chrome下面的情况吧:第三个li正常的渲染到dom树里面,在发生错误的span标签那里,自动补上了一个span的闭合标签
4. 总结
各个浏览器在渲染html的时候表现不一样,尤其是IE浏览器同其他的浏览器。chrome和FF的容错性能很好,即使页面中存在html标签没有正常闭合,它也会智能的进行识别,并使其在浏览器中看上去无恙,且最终的DOM结构也没有问题,然而不好的一面就是你不知道你的代码有错,还以为一切正常。而IE8\9现在也可以这样处理,看上去页面内容没有问题,但是呢,通过开发工具,你可以看到错误的html代码没有正常的DOM结构。但是IE6\7就不会给你这样的机会,要么就直接崩溃了。
chrome可以容许我们犯错,而IE却对我们更加严格,虽然IE让我们很头疼,但是却对我们的代码提出了更高的要求!忽然觉得,有IE也蛮好的。。。
如果有一天,你发现IE下dom结构都无法渲染出来的时候,记得提醒自己,是否代码中有标签没有闭合。
检查bug的步骤
1. bug定位
在js脚本中,按照脚本执行的顺序,你可以用console或alert,来确定bug发生的代码区间,然后在区间内进一步来查找bug发生的具体代码段。
2. bug fix
通过排除,就是在插入节点内容的时候导致了bug,我用的是kissy的DOM.html()方法,其功能类似于DOM元素节点innerHTML方法,我起初认为是这个方法导致的IE6\7渲染出错,然后我换成了innerHTML方法,结果还是有误。
这时候我想到了内存泄露,看看是不是在循环拼接字符串的过程中,有循环引用或者其他原因造成内存泄露,然后在一些方法结束的时候,我把一些变量赋值null,来防止内存泄露(虽然不知道是否有效,但是至少我这么尝试过了),结果还是不行。
是不是数据过多,导致一下子渲染的时候崩溃呢?于是我减少了拼接的数据长度,这个起效了。1~3条数据的时候,可以渲染上,那就说明方法是没有错的;但是3条以上的数据,IE6\7还是无法响应。于是我又试着一条一条数据取持续插入,因为一次插入1条数据没有问题的话,我大不了多插入几次吧,但是IE还是有问题。其实,这时候我的思路已经偏离了。
后来找同事来看看,说之前也碰到过这个问题,是IE6\7下,标签没有正确闭合的原因导致的。没错,这就是这个bug的真正原因啦。后来,我把拼接的字符串打印出来,然后再使用格式化工具进行格式化,变很快发现了我拼接字符串的时候出现的这个问题,于是很快fix掉这个bug。我用的在线格式化工具:http://tool.chinaz.com/Tools/JsFormat.aspx
3. 测试
测试时候,我们写上一串html代码,并对一些标签不闭合,看看IE和chrome对比情况。
代码如下,在第二个li标签里,我们对ul标签中的其中一个<span>标签,做不闭合处理
<ul> <li> <ul> <li>inner li</li> <li>inner li</li> <li>inner li</li> </ul> </li> <li> <ul> <li>inner li</li> <li>inner li</li> <li>inner li <span>not closed<span>error happend</span></li> </ul> </li> <li> <ul> <li>inner li</li> <li>inner li</li> <li>inner li</li> </ul> </li> </ul>
IE 和chrome下都正常显示,如上图。
接下来通过开发工具调试看看。
在IE7~9下面,dom结构错乱,发送错误的地方就在那个没有闭合的<span>标签那里,原来的第三个<li>节点的内容直接插到了<span>节点下面。
我们再来看看chrome下面的情况吧:第三个li正常的渲染到dom树里面,在发生错误的span标签那里,自动补上了一个span的闭合标签
4. 总结
各个浏览器在渲染html的时候表现不一样,尤其是IE浏览器同其他的浏览器。chrome和FF的容错性能很好,即使页面中存在html标签没有正常闭合,它也会智能的进行识别,并使其在浏览器中看上去无恙,且最终的DOM结构也没有问题,然而不好的一面就是你不知道你的代码有错,还以为一切正常。而IE8\9现在也可以这样处理,看上去页面内容没有问题,但是呢,通过开发工具,你可以看到错误的html代码没有正常的DOM结构。但是IE6\7就不会给你这样的机会,要么就直接崩溃了。
chrome可以容许我们犯错,而IE却对我们更加严格,虽然IE让我们很头疼,但是却对我们的代码提出了更高的要求!忽然觉得,有IE也蛮好的。。。
如果有一天,你发现IE下dom结构都无法渲染出来的时候,记得提醒自己,是否代码中有标签没有闭合。
相关文章推荐
- 基于IE下ul li 互相嵌套时的bug,排查,解决过程以及心得介绍
- 基于IE下ul li 互相嵌套时的bug,排查,解决过程以及心得介绍
- IE下ul li 互相嵌套时候的bug,排查,解决过程及心得
- 一个关于 ie 浏览器的 bug 解决过程和思考
- 一个小BUG的解决过程。
- [转]解决IE下CSS背景图片闪烁的Bug
- 今日学习心得:如何做解决数据绑定控件嵌套问题
- IE8下div嵌套时,外层div高度不随内层div高度改变的问题解决
- bb-xm revc移植3 之 xload启动过程略解以及bug的彻底起因和解决
- listview中嵌套gridview时候,getview多次调用的bug
- java.lang.IllegalArgumentException: !hex:1小记微信对账单过程bug解决
- ie focus bug 解决方法
- java 不同意同一账户不同IP 同一时候登录系统解决的方法 兼容IE Firefox
- 写项目的过程,遇见的BUG,如何解决的
- 禅道 bug指向为数字问题解决过程
- 面向过程就是分析出解决问题所需要的步骤,然后用函数把这些步骤一步一步实现,使用的时候一个一个依次调用就可以了;面向对象是把构成问题事务分解成各个对象,建立对象的目的不是为了完成一个步骤,而是为了描叙某个事物在整个解决问题的步骤中的行为(转)
- 记一次排查log4net 不输出日志的解决过程
- 项目调试时候,出现其中用到的一个组件“访问被拒绝”的解决方法(.net的一个BUG)
- 记录一次bug解决过程:eclipse Installed JREs 配置引出的问题
- 记录一次bug解决过程:可维护性和性能优化