Jeff is seeing the same behavior as me, but neither of us can figure out a good way to get a regression range. I'd say 80 or 90% of the time scrolling is absolutely awful, but the other 10 - 20% of the time its normal. Also, the SPS profiler addon on AMO isn't compatible with trunk.

I feel like it may depend on the contents of the page. I notice it on thestar.com

I haven't noticed anything. Is this with any GPU? Are there specific STRs with a stable page.

I've only seen this on pages with plugins, mostly on youtube.

I've also noticed this with plugins.

Can someone who is seeing this confirm give a clear STR? We need a regression window ASAP. My guess is the layers refactoring or bug 860615. Bug 860615 doesn't fit the original report date but we could be mixing in two issues in this bug.

I have reproduced OSX slow scrolling on a Macbook when using two-fingered scrolling on the touchpad. Further I believe I have located the changeset that caused the slowness. To reproduce, using nightly, start with an empty session with no windows, then open http://www.nytimes.com in a new window, and open http://www.zdnet.com/voice-control-showdown-siri-vs-google-now-s-voice-blackberry-and-windows-phone-8_p2-7000014010/#photo in a second new window. Leave the nytimes.com window visible and not minimized to the dock, but click in the zdnet.com window to make it the active window. Using 2 fingers on the touchpad, scroll the page to where the author's biographical info is visible, entitled "About Ben Woods". To cause scrolling to become slow, with the bio visible and the scrollbar in the scrollbar gutter at the edge of the window being vertically moderately towards the center of the window (i.e. make sure the scroll bar is not at either the top of the gutter or at the bottom), put two fingers on the Mac's trackpad, and quickly wiggle your fingers vertically up and down approximately 1 inch. After doing this for a number of seconds, the display of the window should be many seconds behind the user's input, and if you remove your fingers from the touchpad, the window should continue to scroll up and down without any user input until the window catches up with the user's input scroll events. By building Firefox from source and using bisection, on my machine I observe this slowness is present in changeset 128501, and is not present when building at 128500. My Macbook is a 2010 17" Macbook Pro with an nvidia GT330M and integrated Intel graphics. gfxcardstatus shows the integrated Intel graphics is in use when I reproduce this slowness. The machine is a 2.66 GHz dual-core i7 with 8 GB of RAM. If you cannot reproduce this, I am local to Mountain View and I'm willing to bring my Macbook to anywhere nearby for observation.

Peter, you are most likely correct. See also bug 864053. We're working on backing out the patch for bug 851128 right now, it's been causing all this brokenness.

Now that the bad patch from bug 851128 is backed out, this bug should theoretically be fixed. I was never able to reproduce the problem, can somebody who was try it and see if it's still happening?

Note that the backout of bug 851128 didn't land on mozilla-central in time to get into today's mozilla-central nightly. It'll be in tomorrow's.

This should be fixed in current mozilla-central nightlies. Please let us know one way or the other.

This problem appears fixed in the 2013-04-24 nightly: the zdnet.com/...siri... page scrolls without the previous lag. Thanks for the fix.

Marking FIXED on the strength of comment #11. > Thanks for the fix. You're quite welcome.