Steps to reproduce:
1. Open testcase, allow to finish loading (jumps to the end).
2. Click at "click and wait 1"
2. Fx freezes for about 15 s
Jumps to anchor immediately. No freeze.
Created attachment 557562 [details]
Testcase version 0
This regressed between 1.9a7pre: 2007071506 and 1.9a7pre: 2007071605
likely Bug 388019, no?
Stefan, thanks for the testcase!
So the issue here is that we spend 85% of our time constructing line iterators (which involves two walks over the line list: once to count the lines and once to stick them in the array) and then 15% more finding the line containing a given frame.
The reason the construction takes so long is that the <a name="xX"> contains all the text on the page. So when we do the walk over continuations in PresShell::DoScrollContentIntoView we end up calling AccumulateFrameBounds 10498 times. And each call constructs a line iterator for a block that has 14815 lines.
I can make this part faster, but the FindLineContaining cost will still be there, of course. That's bug 682052.
(In reply to Boris Zbarsky (:bz) from comment #4)
> The reason the construction takes so long is that the <a name="xX"> contains
> all the text on the page.
Thanks for the hint, I forgot to close the <a> tags.
> I can make this part faster, but the FindLineContaining cost will still be
> there, of course. That's bug 682052.
Why does it jump so fast with Fx 2?
Because we fixed bug 66619 since then, which involves looking at continuations; that's needed to make multi-line links scroll sanely.
Created attachment 557906 [details] [diff] [review]
Speed up iterating over the continuations of the frame when scrolling to it.
Backed out - https://tbpl.mozilla.org/?tree=Mozilla-Inbound&usebuildbot=1&rev=d01a282b5a40 should be the clearest rev to see the orange from this set, free from the leak that backout fixed.
This patch wasn't the problem; repushed as http://hg.mozilla.org/integration/mozilla-inbound/rev/16813bde78b9