Currently we default the pref for smooth scrolling to off on Windows. There was some reason why this is the case (certain hardware was causing pages to scroll 1 pixel at a time?) Unfortunately I don't know what the exact reason was, although someone cc'd might be able to explain the previous rationale. Can we detect if the environment will correctly allow smooth scrolling, perhaps by looking to see if they are on Windows Vista/7, or if Direct2D is enabled, and then automatically flip the preference so that the user automatically gets the best scrolling behavior? This is also potentially the type of pref we could try flipping for beta 5 so that we could determine the specific set of cases in which pixel-level scrolling does not work for users.
I thought we turned this off because it felt substantially slower (even though it wasn't, just visually it looked slower)?
I've had this enabled for so long, I'd forgotten just how awful the not so smooth scrolling experience was. I'd vote yes. (I believe IE has smooth scrolling on by default as well.)
We shouldn't enable smoothscrolling by default until it works ok with all pages. On older versions (before retained layers), it didn't work well with pages with fixed backgrounds and whatnot, and on the latest nightly, it's just completely broken on all pages, for me (stutters and gets stuck). I don't know why. And even if it's working correctly, we seriously need to improve the algorithm or whatever it is that controls smoothscrolling. Some people get motion sickness from it, and maybe that can be attenuated. Also, smoothscrolling looks awful on **** TFT screens.
Seems better with retained layers, and I agree that it's a better default experience all around. Let's get it done for beta6, and if we find problems with it, we can back it out.
blocking2.0: ? → beta6+
Summary: Enable smooth scrolling by default on Windows (?) → Enable smooth scrolling by default on Windows
I think there should be a way to disable smooth scrolling on a site to site basis. Some pages don't work well with it enabled.
(In reply to comment #6) > I think there should be a way to disable smooth scrolling on a site to site > basis. Some pages don't work well with it enabled. IMHO, that's too complex. Either our smooth scroll code is good enough to generically handle all sites, or it's not and it should remain off until we improve it.
That patch seems to enable smoothscrolling on all platforms.
Please look at bug 593466 before landing this.
Ah yes, I forgot to make it windows only. Should we land this, and then fix bug 593466? Or visa versa?
Attachment #473036 - Flags: ui-review?(faaborg)
Attachment #473036 - Flags: review?(gavin.sharp) → review+
Comment on attachment 473036 [details] [diff] [review] Flip the pref on windows only I've filed and am reviewing, but a few other people in UX have also indicated that they agree with the change.
Attachment #473036 - Flags: ui-review?(faaborg) → ui-review+
Go ahead and land?
(In reply to comment #12) > Go ahead and land? You have the needed reviews. Flip it.
Landed and backed out again. Various tests can't deal with this.
The simplest way to handle this would probably be to let the pref be false in the testing profile.
I must have been drunk when I marked this as blocking beta6+
blocking2.0: beta6+ → ?
(In reply to comment #16) > I must have been drunk when I marked this as blocking beta6+ Your drinking is your own, but I agree that this doesn't block beta6. There a reason you didn't just minus it? In the meantime, minusing -- willing to be wrong, but this feels like "opportunistic, if we can, it might be better" work, not "must happen."
blocking2.0: ? → -
I know this sounds a bit ridiculous, but I'm entirely serious: I think we should consider an entire point release focused on scrolling. There are few things that users do more with our product than scroll, and there are a few areas for us to consider: -getting smooth scrolling turned on -making sure that we are always doing event coalescing correctly (sometimes the browser will continue to scroll after you've stopped providing input) -getting acceleration to work (and dynamically turning it off if the mouse driver appears to already be doing it) -making sure that we have good metrics for monitoring how well we are scrolling (do we have a tscroll?)
Making the test profile differ from what we ship needs to be done carefully. At the very least we should get a list of failing tests and ensure that the failures aren't exposing real issues.
Note related bug 605648 to add support for high resolution mouse scroll events on Windows.
I'm setting this bug to wontfix in favor of bug 605648. High resolution scrolling is better since it doesn't introduce the lag associated with smooth scrolling with a mouse wheel. I've followed bug 623766 to cover using smooth scrolling just for keyboard and scrollbar interactions.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WONTFIX
On Mac, we used to ignore the smooth scrolling pref for pixel scrolling, i.e. pixel scrolling was always instant. That was accidentally regressed in bug 526394 but will be fixed again when bug 607464 lands. We can just treat Windows high resolution scrolling the same as Mac pixel scrolling. Then the patch in this bug is sufficient.
You need to log in before you can comment on or make changes to this bug.