Last Comment Bug 705174 - Scrolling is extremely slow on ftp.mozilla.org/pub/addons onLoad
: Scrolling is extremely slow on ftp.mozilla.org/pub/addons onLoad
Status: RESOLVED FIXED
: regression
Product: Core
Classification: Components
Component: Layout (show other bugs)
: 11 Branch
: x86 All
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
ftp://ftp.mozilla.org/pub/addons/
: 705361 (view as bug list)
Depends on: 524925 675015
Blocks: 100951 381404 599113
  Show dependency treegraph
 
Reported: 2011-11-24 11:32 PST by Anthony Hughes (:ashughes) [GFX][QA][Mentor]
Modified: 2012-02-13 20:53 PST (History)
14 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Peptest for measuring unresponsiveness (607 bytes, text/plain)
2011-11-29 12:20 PST, Andrew Halberstadt [:ahal]
no flags Details

Description Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2011-11-24 11:32:37 PST
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.
Comment 1 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2011-11-24 11:42:09 PST
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?
Comment 2 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2011-11-24 11:47:20 PST
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
Comment 3 Alice0775 White 2011-11-24 12:22:48 PST
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
Comment 4 Alice0775 White 2011-11-24 12:24:00 PST
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
Comment 5 Alice0775 White 2011-11-26 01:40:30 PST
(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.
Comment 6 Alice0775 White 2011-11-26 02:19:36 PST
Workaround: append the following to userContent.css

tbody > tr:hover {
  outline: none !important;
}
Comment 7 Alice0775 White 2011-11-26 10:39:38 PST
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
Comment 8 Andrew Halberstadt [:ahal] 2011-11-29 12:20:00 PST
Created attachment 577700 [details]
Peptest for measuring unresponsiveness

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
Comment 9 Timothy Nikkel (:tnikkel) 2011-11-29 22:57:01 PST
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.
Comment 10 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2011-11-30 00:44:37 PST
Yes, we need bug 524925 here.
Comment 11 Boris Zbarsky [:bz] (Out June 25-July 6) 2011-11-30 12:35:36 PST
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.
Comment 12 Dão Gottwald [:dao] 2011-12-01 00:16:56 PST
*** Bug 705361 has been marked as a duplicate of this bug. ***
Comment 13 Jim Jeffery not reading bug-mail 1/2/11 2011-12-01 09:18:25 PST
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
Comment 14 alex_mayorga 2011-12-01 09:30:06 PST
(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
Comment 15 alex_mayorga 2011-12-01 09:54:02 PST
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/
Comment 16 Boris Zbarsky [:bz] (Out June 25-July 6) 2011-12-01 10:55:42 PST
> 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?
Comment 17 alex_mayorga 2011-12-01 12:27:42 PST
(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.
Comment 18 Timothy Nikkel (:tnikkel) 2012-01-31 18:28:45 PST
This should be fixed now.
Comment 19 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-02-03 17:06:50 PST
(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.
Comment 20 Timothy Nikkel (:tnikkel) 2012-02-03 17:16:29 PST
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.
Comment 21 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-02-06 15:01:37 PST
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.
Comment 22 Timothy Nikkel (:tnikkel) 2012-02-06 15:04:21 PST
They both played a role.
Comment 23 Daniel Cater 2012-02-13 20:00:52 PST
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.
Comment 24 Daniel Cater 2012-02-13 20:01:38 PST
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
Comment 25 Alice0775 White 2012-02-13 20:53:48 PST
Filed Bug 726912

Note You need to log in before you can comment on or make changes to this bug.