Scrolling stutters when mouse pointer moves over a link

RESOLVED WORKSFORME

Status

()

defect
RESOLVED WORKSFORME
9 years ago
8 years ago

People

(Reporter: alexandre.rogozine, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

9 years ago
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.
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.
Blocks: 587908
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 7 → All
Hardware: x86 → All
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.
blocking2.0: --- → ?
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.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Whiteboard: [see comments 2-3 for blocking2.0? rationale]
Target Milestone: --- → Firefox 4.0b8
Had to back out bug 597338, so this will not be fixed in tomorrow's nightly.
Status: RESOLVED → REOPENED
Depends on: 597338
Resolution: FIXED → ---
Target Milestone: Firefox 4.0b8 → ---
(Reporter)

Comment 5

9 years ago
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?
(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/dwillcoxon@mozilla.com-b9b203c9e692/

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

Comment 7

9 years ago
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.
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.
(Reporter)

Comment 9

9 years ago
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. :)
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/
(Reporter)

Comment 11

9 years ago
> 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?
(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.
Bug 605680 will help here too.
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.
blocking2.0: ? → ---
Depends on: 605680, 606304
Whiteboard: [see comments 2-3 for blocking2.0? rationale]
(Reporter)

Updated

8 years ago
Blocks: 595400
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.
Status: REOPENED → RESOLVED
Last Resolved: 9 years ago8 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 16

8 years ago
Opened bug 671640
You need to log in before you can comment on or make changes to this bug.