Heim >Web-Frontend >js-Tutorial >基于IE下ul li 互相嵌套时的bug,排查,解决过程以及心得介绍_javascript技巧

基于IE下ul li 互相嵌套时的bug,排查,解决过程以及心得介绍_javascript技巧

WBOY
WBOYOriginal
2016-05-16 17:34:421464Durchsuche

检查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标签中的其中一个标签,做不闭合处理

复制代码 代码如下:


     

  •   

         
    • inner li

    •    
    • inner li

    •    
    • inner li

    •   

     

  •  

  •   

         
    • inner li

    •    
    • inner li

    •    
    • inner li
         not closederror happend

    •   

     

  •  

  •   

         
    • inner li

    •    
    • inner li

    •    
    • inner li

    •   

     



IE 和chrome下都正常显示,如上图。

接下来通过开发工具调试看看。

在IE7~9下面,dom结构错乱,发送错误的地方就在那个没有闭合的标签那里,原来的第三个

  • 节点的内容直接插到了节点下面。
  • 我们再来看看chrome下面的情况吧:第三个li正常的渲染到dom树里面,在发生错误的span标签那里,自动补上了一个span的闭合标签

    4. 总结

    各个浏览器在渲染html的时候表现不一样,尤其是IE浏览器同其他的浏览器。chrome和FF的容错性能很好,即使页面中存在html标签没有正常闭合,它也会智能的进行识别,并使其在浏览器中看上去无恙,且最终的DOM结构也没有问题,然而不好的一面就是你不知道你的代码有错,还以为一切正常。而IE8\9现在也可以这样处理,看上去页面内容没有问题,但是呢,通过开发工具,你可以看到错误的html代码没有正常的DOM结构。但是IE6\7就不会给你这样的机会,要么就直接崩溃了。

    chrome可以容许我们犯错,而IE却对我们更加严格,虽然IE让我们很头疼,但是却对我们的代码提出了更高的要求!忽然觉得,有IE也蛮好的。。。

    如果有一天,你发现IE下dom结构都无法渲染出来的时候,记得提醒自己,是否代码中有标签没有闭合。

    Stellungnahme:
    Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn