IE 11定位 崩溃复盘

问题背景

• 管理平台在win7 的IE11 上打开，嵌套平台框架，又嵌套多层iframe,当点击某个新建按钮调到编辑页面时，浏览器直接崩溃，什么都没提示

问题分析步骤

• 首先，由于是加载页面时，网页崩溃，那就打断点到研发平台 的生命周期的开始，一步一步跟着断点走，定位到是在renderUI时就崩溃，怀疑是组件渲染的问题；将页面上的组件进行2分法删除，找是由于哪个组件的渲染造成的，结果发现是shrinkPanel的渲染造成，但该组件就100来行代码，初步定位是在this.$el.innerHTML='xxx' 赋值时报错了，所以在其前面加了一句innerHTML='' 好了，以为这样就好了，然后，将所有组件放开，结果不出意外，还是崩了；

• 重新转换方向，因为是iframe嵌套iframe，所以，先将单个页面搂出来，神奇的发现，单个页面居然能打开，好了，排除组件问题了，或许是由于iframe造成的；然后嵌套一层iframe，跳转，不崩,OK，完美；再加一层，跳转崩了，OK,发现新大陆，推测或许是由于平台的跳转造成的，然后就是疯狂测试，看不同的跳转会出现什么变化，结果发现，用的原生的bom location 进行跳转，悲剧，无法进行了。 在测试的过程中，发现只要清一次缓存，就能跳转成功，OK,定位方向发生改变

• 调整定位方向，推测是由于缓存或者性能造成的，因为查找了下，在IE下，iframe卸载后，iframe里面的变量有可能释放不了，还占用内存，所以更加坚定是由于内存性能造成的崩溃，然后一顿操作猛如虎，查找各种卸载iframe时清空内存的方案，测试了各种方案，发现并无卵用；放弃性能造成的崩溃的推测

• 平台的兄弟也一块在定位问题，他们发现，只要把shrinkPanel 屏掉，页面就不会崩溃，然后我又把定位方向转战到shrinkPanel上；将shrinkPanel组件的代码全屏了，发现还是崩溃，说明不是shrinkPanel问题，接着我又将开发自定义的组件屏蔽，发现崩溃；推测有可能是ajax的请求占用了内存导致崩溃（因为在定位过程中，只要ajax请求失败，页面就不会崩溃），所以将所有的ajax屏蔽掉，发现不崩了，所以还是怀疑是性能问题，但是不知道是谁占用了性能，因为shrinkPanel一放开就崩，屏蔽后，放开ajax ，崩。太难定位了，几乎要放弃；

• 过了一周，组长说，和我一块定位，我把一周定位的成果给他说了一遍，我给他说，我还是怀疑是性能导致；他说行，那看下性能，将chrome的任务管理打开，进行操作，发现该页面并没占用多少内存，也就120M，不会导致IE崩溃，就此推翻性能导致的崩溃。 我然后想了下，会不会是样式导致崩溃，通过fiddler将css全部拦截，发现不崩溃了

• 调整方向，往样式方向定位；不抽iframe，就在整个框架上定位崩溃问题；将子页面的css样式屏蔽，放开父页面的css样式（fiddler可以配置正则来匹配捕获的链接），跳转，不崩；将父页面的css屏蔽，放开子页面的css,跳转，崩溃，开心；那就是编辑页面自己的css样式有问题，这下好办，将子页面搂下来，将他的css一个一个放开，跳转，看是由于哪个css样式导致的崩溃（IE9 下对一个css文件里的rule是有限制的，超过后会自动将超出的丢掉）；结果发现是组件核心css有问题（哭了）

• 接着定位组件核心样式哪出了问题，通过二分排除法（就是二分删除发，看删到哪行代代码后，就不崩溃了，一共16800多行样式，哭了，慢慢删，慢慢试呗，谁让IE牛逼，只管崩溃，不管报错）；结果发现删到8000多行后，不报错。接着把所有的css二分成两份，全部引入页面，先将之前8000多行的屏蔽，放开剩下的，跳转崩溃，将剩下的再二分进行排除（注意这块有个组合排除），最后二分到剩余200百行代码的css,只引入这个css都崩溃，那就是这几行css中的代码有问题，想到8000多行时，增加下一个样式就崩溃，考虑是不是那几行css有问题，就将那几行代码屏蔽，好，测试，不崩，80%就是这块的问题，然后将剩余的css全部放开，跳转，不崩，完美，就是这几行css造的孽哈

  .th-inner:empty:afte,
  .cell:empty:afte {
    content: 'empty';
   }
  .shrink-panel:empty:before{}
  

  IE11 下在伪类empty后面跟上伪元素，推测在IE11下 加载时，空伪类会造成重排会很消耗性能，所以IE选择崩溃；将empty伪类换成class 就可以避免该问题

• 至此，定位和修复结束；