Bug 870794 fixed a performance issue in view-source which was caused by fixing an error with bidi isolation, bug 859093. The fix didn't address the root performance problem, it just modified viewsource.css to prevent it arising in view-source, so the problem could resurface in real web pages. This has happened before too: see bug 760954 comment 3.

So view-source is a big <pre> containing a string of <span>s for each line, e.g. <span><span id="line2"></span></span><span>&lt;<span class="start-tag">html</span>&gt;</span> Now the span with the id representing the line number gets unicode-bidi: -moz-isolate, so in bidi resolution for each line of the source we call SplitInlineAncestors, which creates a continuation frame for its parent and reparents all following siblings to the new frame. This is O(n²) in the number of lines. I want to investigate two directions for possible solutions: 1) Swap CreateContinuingFrame round so that the new frame is the continuee of the existing frame instead of its continuation. This would certainly help in the present scenario, but it might well make other stuff more complicated. 2) Make SplitInlineAncestors lazy, e.g. by setting a frame bit instead of actually splitting the frames. The assumption here which may be wrong is that we only need the inline frames to be split in specific places (possibly only in bidi reordering), and we could test the bit there and recurse into descendants.