Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101211 Firefox/4.0b8pre ID:20101211030333 Rrepoted on Forum http://forums.mozillazine.org/viewtopic.php?p=10301741#p10301741 Scrolling is extremely slow and almost unusable on youtube. While scroll is performed, UI of the browser does not response. it is remarkable when I scroll with arrow key with smooth scroll Of course, it happens even if disabled smooth scroll and scroll by mouse wheel. Reproducible: Always Steps to Reproduce: 1. Start Minefield with new profile 2. Enable smooth scroll 3. Open URL ( http://www.youtube.com/user/google#g/u ) 4. Wait till the page finishes completely loading 5. Click empty area of thumbnail scroll box in the page. 6. Try to scroll by arrow key Actual Results: Scrolling is extremely slow and almost unusable. While scroll is performed, UI of the browser does not response. Expected Results: Should not. Regression window(cached hourly): Works: http://hg.mozilla.org/mozilla-central/rev/e3b1c75995ac Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b9pre) Gecko/20110104 Firefox/4.0b9pre ID:20110104030354 Fails: http://hg.mozilla.org/mozilla-central/rev/2a0d0ed04874 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b9pre) Gecko/20110104 Firefox/4.0b9pre ID:20110104005658 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e3b1c75995ac&tochange=2a0d0ed04874
blocking2.0: --- → ?
Target Milestone: --- → mozilla2.0
In local build: build from 2a0d0ed04874 : fails build from e870951c9167 : works So suspected bug: 2a0d0ed04874 Robert O'Callahan — Bug 602892. Part 2: Ensure that a scrollframe is 'inactive' if it can't be scrolled by blitting. r=tnikkel,a=blocking
This is another example of scrolling an element with border-radius and non-visible overflow being slow.
Assignee: nobody → tnikkel
Dupe of Bug 623615 ?
More or less, but let's leave them separate for now.
blocking2.0: ? → final+
In my system (Mac G4, PPC, OS X 10.4.11; SeaMonkey 2.0.12pre), scrolling on all websites is extremely slow if the scroll arrows are used, but normal if dragging or clicking in the scroll bars is used. Selecting or deselecting 'Use smooth scrolling' in the Mac system preferences seems to make no difference at all. This slow scrolling seems to be relatively new as far as updates to SeaMonkey 2.0.x pre are concerned, but I cannot date its appearance exactly.
Further to Comment #5: I see the behaviour described in Comment #5 in the Mail & Newsgroup window also, though possibly it is not quite as extreme as in the browser.
Michael, scrolling with the scroll arrows keys with smoothing scrolling is slower than using the arrow keys which is also the behavior as 3.5 and 3.6. So no changes there. If your finding something different then that, File a bug on Seamonkey.
(In reply to comment #8) > Please retest now that bug 628745 has been fixed. I was considerably improved. http://hg.mozilla.org/mozilla-central/rev/8149e1a06476 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b11pre) Gecko/20110125 Firefox/4.0b11pre ID:20110126103957 However, it slower than http://hg.mozilla.org/mozilla-central/rev/e3b1c75995ac Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b9pre) Gecko/20110104 Firefox/4.0b9pre ID:20110104030354 I tested * Smooth Scroll off * Arrow key / scroll arrow.
That's sounds like about what we expected.
Yeah, bug 602892 is sure to slow down scrolling of border-radius-clipped areas. I think we'll mark this fixed.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
We don't use any more rounded rect clips in FrameLayerBuilder on this page.
It's improved but it's still not fixed as far as I'm concerned, the scrolling is still slow and laggy.
Verified in Mozilla/5.0 (Windows NT 6.1; rv:2.0b11) Gecko/20100101 Firefox/4.0b11
Status: RESOLVED → VERIFIED
Whiteboard: [softblocker] → [softblocker][fx4-fixed-bugday]
You need to log in before you can comment on or make changes to this bug.