User Agent: Steps to reproduce: 1. Open testcase, allow to finish loading (jumps to the end). 2. Click at "click and wait 1" Actual results: 2. Fx freezes for about 15 s Expected results: Jumps to anchor immediately. No freeze.
good 220.127.116.11 bad 3.0.19
This regressed between 1.9a7pre: 2007071506 and 1.9a7pre: 2007071605 Range: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-07-15+06%3A00%3A00&maxdate=2007-07-16+05%3A00%3A00&cvsroot=%2Fcvsroot 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.
6 years ago
6 years ago
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