IE 11 locates a crash recovery

The problem background

  • When you click a new button to switch to the edit page, the browser crashes directly without any prompt

Step of problem analysis

  • First of all, since the page crashed when loading, the break point was at the beginning of the development platform life cycle, step by step to follow the break point, locate the crash when renderUI, suspected component rendering problem; {this.$el.innerhtml =’ XXX ‘;} {this.$el.innerhtml =’ XXX ‘;} So I put a word in front of it that says innerHTML= “Okay, I think I’m done with that, and then I let go of all the components, and as a result, it just crashes;

  • If an iframe is nested within an IFrame, you can open a single page. If an IFrame is nested within an iframe, you can open a single page. If an IFrame is nested within an iframe, you can open a single page. Then nest a layer of iframe, jump, not collapse,OK, perfect; A new continent was found. It was speculated that this might be caused by the jump of the platform. Then it was a crazy test to see what changes would appear in different jumps. During the test, it was found that the jump was successful as long as the cache was cleared once. OK, the positioning direction changed

  • Adjust positioning direction, that is caused by the cache or performance, because find, in IE, iframe after unloading, the inside of the iframe variables likely won’t release, also takes up memory, so more determined collapse is caused by memory performance, and then a fierce like a tiger, operation to find various uninstall the iframe empty memory, Various schemes were tested and found to have no use for eggs; Drop speculations of performance-induced crashes

  • The platform’s brothers are also trying to locate the problem. They noticed that as soon as I took off the shrinkPanel, the page wouldn’t crash, then I switched to the shrinkPanel. ShrinkPanel is not a problem with shrinkPanel. Then I will develop a custom component shield, and it crashes. Speculated that it is possible that the ajax request has occupied memory lead to breakdown (because in the process of positioning, as long as the ajax request fails, the page doesn’t crash), and so will all the ajax block, found not collapse, so still doubt is a performance problem, but don’t know who take up performance, because shrinkPanel as soon as you let go of the collapse, shielding, Let go of Ajax, crash. Too difficult to locate, almost give up;

  • After a week, the leader said, positioning with me, I put the results of positioning a week to him again, I told him, I still doubt is caused by performance; He said ok, look at the performance, open chrome task management, perform operations, found that the page does not take up much memory, that is 120MB, will not cause IE to crash, which overturns the performance caused crash. I then wondered if it was the style that was causing the crash. I used Fiddler to intercept all the CSS and found it didn’t crash

  • Adjust the direction to the style orientation; Locate crash issues on the entire framework without iframe extraction; The CSS style of the child page is shielded, and the CSS style of the parent page is released (Fiddler can configure regex to match captured links), jump, and not collapse; The parent page CSS shield, let go of the child page CSS, jump, crash, happy; There is a problem with editing the CSS style of the page, which is easy to do, put the sub-page down, release its CSS style one by one, jump, see which CSS style is caused by the crash (IE9 for a CSS file rule is limited, after the exceed will automatically throw away the excess); Turns out it was the component core CSS that had the problem (crying)

  • Then locate the component core style which problem, through binary elimination method (is binary delete hair, see delete to which line of code, will not crash, a total of 16800 lines of style, cried, slowly delete, slowly try bai, who let IE niubi, just crash, regardless of error); It was found that no error was reported after deleting more than 8000 lines. Then put all of the CSS into two portions, all into the page, before the first of more than 8000 lines of shielding, let go of the rest, jump to collapse, the remaining half again to exclude (note that this is a combination rule out), the final binary CSS to the remaining 20000 lines of code, only to introduce the CSS collapse, it is this in a few lines of CSS code has a problem, Think of more than 8000 lines, add the next style on the crash, consider whether there is a problem with a few lines of CSS, the lines of code will be shielded, good, test, not collapse, 80% is the problem, and then all the rest of the CSS release, jump, not collapse, perfect, is this few lines of CSS made sin ha

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

    IE11 follows the pseudo-element behind the pseudo-class empty. It is speculated that when IE11 is loaded, the empty pseudo-class will cause rearrangement and consume performance very much, so IE chooses to crash. This problem can be avoided by replacing the Empty pseudo-class with class

  • At this point, positioning and repair are complete;