Open
Bug 503732
Opened 15 years ago
Updated 2 years ago
scrollbar arrow buttons scroll at a slower pace if smooth scrolling is enabled (regression in 3.5)
Categories
(Core :: Web Painting, defect)
Tracking
()
NEW
People
(Reporter: canon138545, Unassigned)
References
()
Details
(Keywords: perf, regression)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5 See "Steps to Reproduce" Reproducible: Always Steps to Reproduce: 1. Go to a web page that is long enough to be scrolled for a few seconds. 2. Using a stopwatch and the vertical scrollbar GUI arrow buttons (not the keyboard arrow buttons), time how long it it takes to scroll from the top to the bottom of the page with smooth scrolling turned OFF. 3. Repeat the previous step with smooth scrolling turned ON. 4. Optionally repeat steps 1 through 3 with Firefox 3 to see how this has changed from version 3 to version 3.5. Actual Results: Actual results will vary but the point is that the arrow buttons are significantly slower when smooth scrolling is turned on. For example, using 1024x768 screen resolution and the 9 July 2009 revision of http://en.wikipedia.org/wiki/Bugzilla, I get around 4.8 seconds with smooth scrolling turned off and around 8.1 seconds with smooth scrolling turned on. Expected Results: The scrollbar arrow buttons should scroll at a reasonable speed when smooth scrolling is turned on, as they did in version 3. Ideally, if it takes 4.8 seconds to scroll from top to bottom of a particular page with smooth scrolling off, then it should take in the neighborhood of 4.8 seconds with smooth scrolling on.
Comment 1•15 years ago
|
||
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.1pre) Gecko/20090710 Shiretoko/3.5.1pre I can imagine that de video card has to do more while scrolling smoothly, but you say it's a regression. Personally I see no difference (on this computer).
Keywords: regression
Product: Firefox → Core
QA Contact: general → general
Version: unspecified → 1.9.1 Branch
Comment 2•15 years ago
|
||
With another URL I can indeed reproduce delay. This bugzilla query URL: https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=bookmarks%20tabs&product=Core&product=Firefox&product=Tech+Evangelism&product=Toolkit&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&resolution=INVALID&resolution=WONTFIX&resolution=DUPLICATE&resolution=WORKSFORME&resolution=EXPIRED&resolution=MOVED&resolution=---&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2005-06-01&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse%20same%20sort%20as%20last%20time&field0-0-0=noop&type0-0-0=noop&value0-0-0= It is a delay of about ~30%-35%. Regression range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=80ebf9e83648&tochange=cfc553938038 which points to Bug 463042. I can also confirm that the bug was not yet present before Bug 457864 was fixed. So one of the two has caused the issue.
Component: General → Layout: View Rendering
Keywords: perf
QA Contact: general → layout.view-rendering
Updated•15 years ago
|
Updated•15 years ago
|
Flags: blocking1.9.2?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.9.2? → wanted1.9.2+
Assignee | ||
Updated•6 years ago
|
Component: Layout: View Rendering → Layout: Web Painting
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•