726468 - Scrolling gets stuck permanently if I scroll using both the trackpad and keyboard

Status: NEW

(Core :: Web Painting, defect)

Description

[Jesse Ruderman]

1. Load any long page, e.g. https://developer.mozilla.org/en/CSS/linear-gradient
2. Start scrolling down using two fingers on the trackpad.
3. While scrolling with the trackpad, press the spacebar.

Result: about 40% of the time, scrolling stops and the page becomes unscrollable.

Workaround: reload the page.

I hit this about once a day, but only figured out the STR today.  I think it started about a month ago, although it's possible that it started when I upgraded from Snow Leopard to Lion.

Comment 1

[Jesse Ruderman]

It can also be unstuck by dragging the scrollbar.

Comment 2

[Alex Keybl [:akeybl]]

It's unclear that this is a recent regression, or that any significant percentage of our user population would run into these STR. We've decided not to track for release.

Comment 3

[Tim Taubert [:ttaubert] (inactive)]

Can reproduce on OS X 10.6.8.

Comment 4

[Tim Taubert [:ttaubert] (inactive)]

Regression range:

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=047c8ba7d2e4&tochange=34572943a3e4

Caused by bug 198964. Scrolling doesn't get stuck when turning off 'smooth scrolling'. Reproducible when turned on again.

Comment 5

[Timothy Nikkel (:tnikkel)]

What about with smooth scrolling forced on, is this a regression or has it always been like that?

The thing that might affect this that comes to mind is http://hg.mozilla.org/mozilla-central/rev/3dbddbb05ae4

Comment 6

[Timothy Nikkel (:tnikkel)]

Selecting some text seems to restore the ability to scroll.

Comment 7

[Tim Taubert [:ttaubert] (inactive)]

(In reply to Timothy Nikkel (:tn) from comment #5)
> What about with smooth scrolling forced on, is this a regression or has it
> always been like that?

Good question, trying some more builds.

> The thing that might affect this that comes to mind is
> http://hg.mozilla.org/mozilla-central/rev/3dbddbb05ae4

That's not the culprit. Build from early March 2011 shows this issue, 2009-01-01 does not.

Comment 8

[Timothy Nikkel (:tnikkel)]

Thanks for checking. My next guess would be bug 526394 (it landed 2010-01-11).

Comment 9

[Tim Taubert [:ttaubert] (inactive)]

Tracked it down to:

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=094a7967e171&tochange=847a825087f2

I guess it might be bug 607464?

Comment 10

[Timothy Nikkel (:tnikkel)]

Most likely.

Comment 11

[Timothy Nikkel (:tnikkel)]

The problem is in nsGfxScrollFrameInner::ScrollTo if we have an existing mAsyncScroll we can change the value of mAsyncScroll's mIsSmoothScroll variable, but that doesn't make any change to mAsyncScroll's existing timer (repeating vs one shot), and we can be left with a non-null mAsyncScroll whose timer is not going to fire again.

Comment 12

[Timothy Nikkel (:tnikkel)]

Ah yes, I think found this problem while debugging bug 629587 but it was just theoretical, I couldn't find any problems it caused. It also seems like this problem is also causing bug 723027.

Comment 13

[Timothy Nikkel (:tnikkel)]

So we need to do something smart when we get a ScrollTo call while an mAsyncScroll of a different type is active. We might need to pass another argument giving us a bit more info about the intention of the scroll call so we can decide if we should cancel the existing scroll or the new one, or add it on to the existing one or what exactly.