600635 - Scrolling stutters when mouse pointer moves over a link

Status: RESOLVED WORKSFORME

(Firefox :: General, defect)

Description

[Alex]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; rv:2.0b7pre) Gecko/20100929 Firefox/4.0b7pre
Build Identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0b7pre) Gecko/20100929 Firefox/4.0b7pre

Scrolling is smoother when the mouse pointer is not in the area being scrolled. 
When scrolling and the mouse pointer focuses on a link there is stuttering.

Reproducible: Always

Steps to Reproduce:
1. Open a page with lots of links.
2. Make sure the mouse pointer is in the scrolled area.
3. Make sure that when the page is scrolled, mouse arrow will pass over a link.
4. Scroll the page using the arrow keys.
Actual Results:  
Scrolling speed is consistent UNTIL the mouse pointer finds itself over a link.
Scrolling stutters when the arrow passes over a link and becomes a hand.

Expected Results:  
Scrolling speed should be consistent whether or not the mouse arrow passes a link when scrolling.

D2D is manually disabled. DTA! Dev && ABP Dev.
This behavior seems unique to FF only.

Comment 1

[Drew Willcoxon :adw]

Confirming.  This has the same root cause as bug 597338 and should be fixed by the patch there.  When I try on a page with a lot of links (http://www.dmoz.org/Arts/) without that patch, I can reproduce; with the patch, it's much better.  Bug 597896 would also fix this, and while I'd like to land that for Firefox 4, I haven't started on that yet.

Thanks for filing the bug.

Comment 2

[Drew Willcoxon :adw]

Since this affects web pages and not bookmark- and other tab-related UI, we may want to fix this sooner than bug 597338's beta N.

Comment 3

[Drew Willcoxon :adw]

Bug 597338 landed, and that should fix this bug too.  If you can reproduce on tomorrow's nightly build (build 20101013) or later, then please reopen this bug.

I'm leaving the blocking2.0? status in case drivers think this is worth fixing on the beta7 branch.

Comment 4

[Drew Willcoxon :adw]

Had to back out bug 597338, so this will not be fixed in tomorrow's nightly.

Comment 5

[Alex]

This is one of the few bugs which make FF unbearably slow thus it would be of interest to have this in beta7 if possible.

Question, how come just landing 597338 was satisfactory for marking this bug as resolved? Shouldn't this be marked fixed after some sort of a throttling mechanism for detection of the mouse pointer location when scrolling w. arrow keys?

Comment 6

[Drew Willcoxon :adw]

(In reply to comment #5)
> Question, how come just landing 597338 was satisfactory for marking this bug as
> resolved? Shouldn't this be marked fixed after some sort of a throttling
> mechanism for detection of the mouse pointer location when scrolling w. arrow
> keys?

The fix to bug 597338 is basically such a throttling mechanism.  If it turns out bug 597338 doesn't fix this bug then by all means we'll reopen it and attempt to track down the real cause.  But in my testing, it does fix it.

Actually you can try out a test build with the patch to bug 597338 applied.  If you can reproduce using it, please let me know.

http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/[e-mail]-b9b203c9e692/

(These will be automatically deleted in four to ten days.)

Comment 7

[Alex]

Do I have to create a new profile to test this? Maybe wrong build link?

Scrolling over hyperlinks still causes stuttering. Bookmark highlight causes CPU strain and if I move the mouse pointer up and down quickly (over my bookmarks), I can see the animation trying to keep up with me.

Comment 8

[Drew Willcoxon :adw]

That's the right link.  Did you run the build with MOZ_NO_REMOTE=1?  Otherwise you'll just get a new window in the build you already have open.  (Or you could just close all instances of Firefox and then try the build, but I recommend using a temp profile regardless since this is a test build.)

Also, the link target will keep up with you if you mouseover at a slow or moderate speed.  When you move quickly, as scrolling with the arrow keys should, the target should remain constant until you come to a stop or briefly settle over a link.

Comment 9

[Alex]

With a new profile, the problem is still there. It maybe decreased in severity, but nonetheless still noticeable.

I am on a netbook - there is a lack of power for both GUI Rendering && Scrolling. Once performance bugs for scrolling and GUI will be fixed, this might not be an issue. :)

Comment 10

[Drew Willcoxon :adw]

Thanks for trying the build.

Profiles aren't the important part -- just to be clear, did you close all instances of Firefox before trying the test build or use MOZ_NO_REMOTE?  The important part is that you really tried the test build and not a new window in your normal Firefox installation.

> I am on a netbook - there is a lack of power for both GUI Rendering &&
> Scrolling. Once performance bugs for scrolling and GUI will be fixed, this
> might not be an issue. :)

Well, you said that the problem only occurs when the cursor falls over a link, so I think general scrolling performance is unrelated.

Your user agent string in comment 0 indicates you're running the nightly.  Did you notice this problem before 9/15's nightly?  That's when we started showing link targets in the location bar.  Here's the day before's build, which should not show link targets in the location bar:

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010/09/2010-09-14-04-mozilla-central/

Comment 11

[Alex]

> Well, you said that the problem only occurs when the cursor falls over a link,
> so I think general scrolling performance is unrelated.

Well, my logic was like this,
(Scroll perf. = horrible*) -> (little power left )
(Optimized Scrolling     ) -> (more power left   )
(more processing power   ) -> (less stuttering   )

I'd wait until that is fixed to eval. this further.

> Your user agent string in comment 0 indicates you're running the nightly.  Did
> you notice this problem before 9/15's nightly?  That's when we started showing
> link targets in the location bar.  Here's the day before's build, which should
> not show link targets in the location bar:

Same thing as the current trunk which has your fixes.
Scrolling is *slightly* slower when scrolling over links - micro-stuttering.

Maybe someone else can chirp in some feedback?

Comment 12

[Drew Willcoxon :adw]

(In reply to comment #11)
> Same thing as the current trunk which has your fixes.
> Scrolling is *slightly* slower when scrolling over links - micro-stuttering.

OK, so based on what you're saying it sounds like there were two problems: 1) scrolling was much slower with link targets in the location bar, and bug 597338 fixed that, except 2) scrolling was slightly slow even before link targets in the location bar.  After problem 1 was fixed, it's now back to problem 2 levels.  Is that right?

Without hard data it's hard for me or you to speak with much certainty, like what "slightly" means for example, or if the current trunk's "slightly" is bigger or smaller than 9/14's "slightly".  It's possible that updating the old status bar on link hover caused a slight slowdown if called many times.

Comment 13

[Drew Willcoxon :adw]

Bug 605680 will help here too.

Comment 14

[Drew Willcoxon :adw]

Turns out beta 7 will include bug 597338 and bug 605680 after all, so removing blocking? flag.

And not related to beta 7 but to link target performance generally, hopefully bug 606304 will land soon, too.

Comment 15

[Drew Willcoxon :adw]

The feature that caused this bug was backed earlier this year.  If you still notice the problem in recent versions of Firefox, it has a different cause, so please open a new bug.

Comment 16

[Alex]

Opened bug 671640