Today I noticed that scrolling performance is extremely sluggish on ftp.mozilla.org/pub/addons/ for a minute or so after page load. Once everything gets cached, it seems to be fine; until I reload the page. Steps to reproduce: 1) Go to ftp://ftp.mozilla.org/pub/addons/ 2) Wait for page load (throbber stops animating and favicon appears) 3) Scroll down Result: Very sluggish Expected: Smooth scrolling This was found using the latest Mac Nightly. I will now investigate whether this happens on previous versions of Firefox and try to narrow down a regression range.

This does not appear to be a performance regression as I can reproduce this going back to 3.6.23. I did notice, however, that the more I reload the better the scrolling performance on this page. Maybe cache is playing a role here?

Another thing I have noticed is that clicking the scroll "blob" and dragging it down is smooth. So too is pressing the down/up buttons on the scrollbar. It only appears to be keyboard and trackpad scrolling which is sluggish. To summarize: * Trackpad scrolling: sluggish * Keyboard scrolling: sluggish * Scrollbar block: smooth * Scrollbar arrows: smooth

It smooth if mouse pointer stays on the gray border zone at the both side of folder lists . However, it sluggish if mouse pointer put over folder links. And I noticed that The movement of the focus ring delays when I move mouse pointer on the list of folders up and down

I forgot build id http://hg.mozilla.org/mozilla-central/rev/de483d897af4 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0a1) Gecko/20111124 Firefox/11.0a1 ID:20111124031031

(In reply to Alice0775 White from comment #3) > It smooth if mouse pointer stays on the gray border zone at the both side of > folder lists . > However, it sluggish if mouse pointer put over folder links. > > And I noticed that > The movement of the focus ring delays when I move mouse pointer on the list > of folders up and down Bug 705361 is related to the above.

Workaround: append the following to userContent.css tbody > tr:hover { outline: none !important; }

At least there are 3 regressions. #1 regression window: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9a6pre) Gecko/20070618 Minefield/3.0a6pre Slightly slower move focusring: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9a6pre) Gecko/20070619 Minefield/3.0a6pre Suspected: Bug 381404 - nsFocusController::MoveFocus() should indicate failure #2 regression window: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9a7pre) Gecko/2007072104 Minefield/3.0a7pre Slightly slower scroll speed: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9a7pre) Gecko/2007072205 Minefield/3.0a7pre Suspected: Bug 321447 - Allow slower minimum speed for autoscroll #3 regression window: http://hg.mozilla.org/mozilla-central/rev/65d85a6e96d7 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101013 Firefox/4.0b8pre ID:20101014182209 Slightly slower scroll speed: http://hg.mozilla.org/mozilla-central/rev/417a9fc988ec Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101014 Firefox/4.0b8pre ID:20101014190723 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=65d85a6e96d7&tochange=417a9fc988ec Suspected: Bug 599113 - changing style due to :hover and then scrolling part of style-changed element in shows old style in scrolled-in area

I wrote a peptest for this issue, unresponsiveness is clearly visible. I discovered that it is enough to simply TAB through the links to generate unresponsiveness. If you want to run this test yourself you can follow the steps here: https://wiki.mozilla.org/Auto-tools/Projects/peptest#Running_Tests Here is sample output from the test: PEP TEST-START | test_ftpmoScrolling.js PEP WARNING | test_ftpmoScrolling.js | scroll | unresponsive time: 684 ms PEP WARNING | test_ftpmoScrolling.js | scroll | unresponsive time: 365 ms PEP WARNING | test_ftpmoScrolling.js | scroll | unresponsive time: 69 ms PEP WARNING | test_ftpmoScrolling.js | scroll | unresponsive time: 339 ms PEP WARNING | test_ftpmoScrolling.js | scroll | unresponsive time: 316 ms PEP WARNING | test_ftpmoScrolling.js | scroll | unresponsive time: 331 ms PEP WARNING | test_ftpmoScrolling.js | scroll | unresponsive time: 319 ms PEP WARNING | test_ftpmoScrolling.js | scroll | unresponsive time: 329 ms PEP WARNING | test_ftpmoScrolling.js | scroll | unresponsive time: 319 ms PEP WARNING | test_ftpmoScrolling.js | scroll | unresponsive time: 331 ms PEP WARNING | test_ftpmoScrolling.js | scroll | unresponsive time: 321 ms PEP WARNING | test_ftpmoScrolling.js | scroll | unresponsive time: 328 ms PEP WARNING | test_ftpmoScrolling.js | scroll | unresponsive time: 331 ms PEP WARNING | test_ftpmoScrolling.js | scroll | unresponsive time: 332 ms PEP WARNING | test_ftpmoScrolling.js | scroll | unresponsive time: 320 ms PEP WARNING | test_ftpmoScrolling.js | scroll | unresponsive time: 329 ms PEP WARNING | test_ftpmoScrolling.js | scroll | unresponsive time: 319 ms PEP WARNING | test_ftpmoScrolling.js | scroll | unresponsive time: 331 ms PEP WARNING | test_ftpmoScrolling.js | scroll | unresponsive time: 320 ms PEP WARNING | test_ftpmoScrolling.js | scroll | unresponsive time: 328 ms PEP WARNING | test_ftpmoScrolling.js | scroll | unresponsive time: 320 ms PEP TEST-UNEXPECTED-FAIL | test_ftpmoScrolling.js | fail threshold: 0.0 | metric: 2516.261 PEP TEST-END | test_ftpmoScrolling.js | finished in: 17214 ms

So we have hover styles that apply outline when you hover a row, nsStyleOutline::CalcDifference makes us reflow the frame when we go from no outline to an outline. And this makes us reflow the giant table with a row for every file in the directory. Do we need to reflow on outline changes? Don't we change at most the overflow area of the frame? If so maybe we could piggy back off bug 524925 and just update the overflow area in this case.

Yes, we need bug 524925 here.

There are also hover styles for the anchors that change text-decoration; not sure whether we need to reflow for that. The other thing that would help would be bug 675015.

Does this site suffer the same as this bug: http://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?path=Win/ Get slow script-warnings and page really never finishes.. Also got a 'not responding' grey out on Win7 x64 running latest m-c hourly build win32 with cset: https://hg.mozilla.org/mozilla-central/rev/e68aa21fd927

(In reply to Jim Jeffery not reading bug-mail 1/2/11 from comment #13) > Does this site suffer the same as this bug: > > http://commondatastorage.googleapis.com/chromium-browser-snapshots/index. > html?path=Win/ "A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete. Script: http://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?path=Win/:206" The page is forever "Connecting..." and eventually this crash happened bp-1b1442a9-00ed-4a24-bdd4-c615f2111201

I can make Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:11.0a1) Gecko/20111201 Firefox/11.0a1 ID:20111201031025 crash on queue. STR: - Load http://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?path=Win/ - Let Script: http://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?path=Win/:206 continue - Click "Back" button when the page is forever "Connecting..." RESULT Crash like bp-1e51896e-155e-4bf6-b689-9a4ea2111201 Might be of interest, on the restored session after the crash the URL for the site looks like this: wyciwyg://0/http://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?path=Win/

> Get slow script-warnings Then it's almost certainly a different issue. Please file a separate bug, move the data from comment 14 and comment 15 there, and cc me?

(In reply to Boris Zbarsky (:bz) from comment #16) > > Get slow script-warnings > > Then it's almost certainly a different issue. Please file a separate bug, > move the data from comment 14 and comment 15 there, and cc me? Filed bug 706932 and cc'd you as requested.

This should be fixed now.

(In reply to Timothy Nikkel (:tn) from comment #18) > This should be fixed now. Fixed in what? This is still pretty sluggish in Firefox 11.0b1 for me.

Fixed by the usual standards we mark bugs as fixed by, when they land/are fixed in mozilla-central. In this case the bugs that have improved this have made their way to Aurora by now.

Seems to fixed for me now on Firefox Aurora 12.0a2 2012-02-06. I'm not sure which bug fixed this, bug 524925 or bug 675015 or both, but it definitely seems to be fixed now.

They both played a role.

The page is still extremely slow to scroll for me when the cursor is inside the middle section. When it is not, scrolling is fine.

I forgot to mention that this is using the latest nightly. Mozilla/5.0 (X11; Linux x86_64; rv:13.0a1) Gecko/20120213 Firefox/13.0a1

Filed Bug 726912