User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120314 Firefox/14.0a1 Build ID: 20120314130626 Steps to reproduce: Avih suggested that the pixel scrolling needs some tweaking, and indeed when doing small scrolling increments the default behaviour isn't very snappy. Infact compared to Beta and Release, scrolling 3 lines now takes a full second during the glide animation which to some may be somewhat annoying. My suggestion is changing the smooth scroll checkbox into a drop down menu that offers varying degree's of smoothness, with the most responsive of them setting general.smoothScroll.pixels.durationMaxMS and general.smoothScroll.pixels.durationMinMS to 150, which is far less "delayed" and offers similar responsiveness to the original implementation.

Clarification: I suggested that some would find the current default laggy, and that adding a more accessible UI could be useful. Another UI option instead of the suggested drop-down is to have an extra checkbox at the "Use Smooth scrolling" line: "Even softer" or "Snappy" etc. (these examples represent opposite prefs). If using this extra checkbox, then it should probably stay disabled if "Use smooth scrolling" is not checked. Changes to the code from bug 206438, and at the config dialog, should be quite minimal. If this gets resolved quickly and nicely, I even suggest backporting it to Firefox 13.

At the configuration dialog (Advanced -> General) at the same line of "Use smooth scrolling", add a checkbox "Quick and fixed duration" (which is only enabled when "Use smooth scrolling" is checked). This forces all smooth scroll triggers to 150ms, non-dynamic (same as pre Firefox 13). Not checked by default. Since we now allow "legacy" behavior via accessible UI, this patch also increases the default maximum duration for "lines" triggers (= keyboard arrows only) from 150ms to 300ms. The minimum stays 150ms (which is used for high events rate, such as if the arrow key is held down).

I've pushed this patch to the UX build so it can get some testing from the UX team. It should show up in tomorrows UX Nightly update. https://tbpl.mozilla.org/?tree=UX&rev=6176ae333309

I also thought one of the first patches was nice because it seemed fast and fluid when testing some of the UX builds before, but I also just disabled smooth scrolling for the same reason and it felt laggy and too slow. Maybe I'm outside the norm, but the final implementation felt like I was waiting for the computer when I wanted it to be there already. With that in mind, I couldn't tell how to tweak the prefs (I tried setting both min/max lines to 15 to fix it) since I didn't get what changed in the code between the older and final patch.

Comment on attachment 606540 [details] [diff] [review] Allow legacy smooth-scroll behavior + UI We should not have a pref in the UI for this. If general.smoothScroll.pixels.durationMaxMS is too high, we should fix that.

(In reply to Dão Gottwald [:dao] from comment #5) > Comment on attachment 606540 [details] [diff] [review] > Allow legacy smooth-scroll behavior + UI > > We should not have a pref in the UI for this. If > general.smoothScroll.pixels.durationMaxMS is too high, we should fix that. I don't believe we can find a value which will satisfy everyone, the same as we can't say that everyone like smooth scrolling in general. It's a highly personal preference. I can say from my experience with SmoothWheel for almost 10 years now, that while many people absolutely love the longer duration and can't live without it anymore, others hate it with a passion and find it extremely laggy (and I acknowledge it even if I'm the author of SmoothWheel, and I do prefer the long+dynamic duration). The longer+dynamic duration for smooth scrolling has already made it into Firefox 13 by default recently (bug 206438), despite my warnings (bug 206438 comments 16,18), but we haven't provided an accessible UI to choose the more conventional approach of quick and non dynamic duration, which is what this patch tries to do. I would appreciate a reconsider of this reject.

[quote]Allow legacy smooth-scroll behavior + UI We should not have a pref in the UI for this. If general.smoothScroll.pixels.durationMaxMS is too high, we should fix that.[/quote] we shouldn't have people like you providing input for UI changes. MaxMS is only one part of the problem.

(In reply to Avi Halachmi (:avih) from comment #6) > I don't believe we can find a value which will satisfy everyone, We need to find the best values for the majority. Beyond that we have about:config and add-ons (such as SmoothWheel). In general, we're very hesitant towards exposing new preferences. They tend to be abused as a cheap way to escape the "what should be the default setting" discussion. That's not a good escape, because 1) we should still have that discussion for the bulk of users who don't change preferences and 2) exposing all implementation details that someone might want to tweak would render the preferences UI unusable.

(In reply to Dão Gottwald [:dao] from comment #8) > (In reply to Avi Halachmi (:avih) from comment #6) > > I don't believe we can find a value which will satisfy everyone, > > We need to find the best values for the majority. Beyond that we have > about:config and add-ons (such as SmoothWheel). In general, we're very > hesitant towards exposing new preferences. They tend to be abused as a cheap > way to escape the "what should be the default setting" discussion. That's > not a good escape, because 1) we should still have that discussion for the > bulk of users who don't change preferences and 2) exposing all > implementation details that someone might want to tweak would render the > preferences UI unusable. I agree, and I'm actually as reluctant as yourself when it comes to expanding the UI as a cheap replacement for working hard to find good defaults. However, sometimes, in order to innovate, you need to go a bit far compared to what most people are used to. Such was the case, for example, with removing the main menu from Firefox - you cannot force it upon people or else some would just go away and use the competition instead. So you give them an accessible way to revert to the more common and familiar approach. Since scrolling is an essential and central activity to web browsing, and this is a quite noticeable change in behavior, I believe this case is similar. The vast majority of other applications (and Firefox itself prior to version 13) use a very quick animation, and this is what people are used to. So the reasons are: 1. It's good as default, but it's a big change from the common approach (especially combined with Firefox 13 turning smooth scrolling on by default). 2. People don't like being forced to a big change, but they're much more willing to try if they know they can go back at any time. 3. Some people absolutely don't want to get used to it. 4. A middle ground will not satisfy those who hate it, and yet still not fulfill its potential for the rest. 5. This far from "exposing all implementation details". Rather it's "providing a switch which brings back the familiar". This checkbox really isn't an afterthought, and I've noted more than once, before resolving bug 206438, that some UI consideration will be required, for the exact reasons which I've stated here.

Firefox <13 uses no animation at all by default. That pref is still there.

dao, it'd be nice if you actually understood the problem, since you don't can you just not comment?

How about setting the maximum duration to 150ms for all cases, for now? Then wait while the changes settle, and then consider as a separate bug whether to increase the pixel scrolling max duration.

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #12) > How about setting the maximum duration to 150ms for all cases, for now? Then > wait while the changes settle, and then consider as a separate bug whether > to increase the pixel scrolling max duration. Doing that would be keeping the behavior almost identical to Firefox 12, so no change would be noticeable, hence nothing to "settle". My analysis (bug 206438 comments 16, 17) came down to longer+dynamic duration and "soft-edge" (bug 206438 comments 63, 69), and the duration change is the major of those two.

It can be helpful to separate the accidental regressions from the deliberate changes.

Sounds reasonable in general, but I'm not sure I know how to apply it to this conversation.

I'm summarizing few discussions over IRC with roc and dao: roc suggests: make bug 206438 only modify the infrastructure (and keep all durations as previously: 150ms), and open a new bug to discuss default values. dao suggests: find a middle ground value (he suggests 400ms based on mak's preference and his own guestimate). I can live with 400ms, or even a complete rollback to 150ms, but I strongly suggest to conduct a user study to see how users' preference distribute, and take it from there. Summary of users feedback so far regarding smooth scrolling for Firefox 13a from http://input.mozilla.com/en-US/?q=scroll&product=firefox&version=13.0a1 : 2 - very negative 3 - negative 1 - would like to control the duration himself (finds it slow) 3 - very positive 2 - probably point to bug 728738 (glitches in smooths scrolling) FYI.

Does this pref control [b]mousewheel.enable_pixel_scrolling[/b] ? I had to turn off the above, scrolling was just too janky to be of use. Sometimes is would scroll ok, others it would crawl, and leap down the page, pause and then actually scroll 'up' as if it was seeking a center point.. Very annoying. Turning off the pref stopped the jank. I have not changed the pref under discussion here to see if it makes any difference. for reference: general.smoothScroll.pixels.durationMaxMS ?

(In reply to Jim Jeffery not reading bug-mail 1/2/11 from comment #18) > Does this pref control [b]mousewheel.enable_pixel_scrolling[/b] ? > > I had to turn off the above, scrolling was just too janky to be of use. > Sometimes is would scroll ok, others it would crawl, and leap down the page, > pause and then actually scroll 'up' as if it was seeking a center point.. > Very annoying. Turning off the pref stopped the jank. > > I have not changed the pref under discussion here to see if it makes any > difference. > for reference: general.smoothScroll.pixels.durationMaxMS ? Disabling mousewheel.enable_pixel_scrolling appears to force the mouse wheel to generate "line" scroll events (instead of the default "pixels"), and lines have not changed, hence, still using 150ms. If you keep mousewheel.enable_pixel_scrolling disabled, then general.smoothScroll.lines.durationMaxMS will control the maximum duration for both KB arrows and mouse wheel. The preference which is discussed in this bug is general.smoothScroll.pixels.durationMaxMS . It was 150ms, and now it's dynamic between 200-800ms, depending on the speed at which you roll the mouse wheel. Currently pixels scrolls are generated only by mouse wheel rotation (and touchpads).

On Windows it might depend on the specific hardware and driver in use, but on Mac and Linux we never get pixel scroll events to scroll frames that ask for smooth scrolling. Sounds like you've only changed the behaviour for (some subset of) Windows users.

I also believe that 800ms is a bit too high of a ceiling value and makes the scrolling on shorter inputs seem less responsive. After doing some more testing on Windows with particular focus on short scroll distances, it looks like 400ms is a good default. We should change it to 400ms, and land this, as well as backport that change in value to Aurora.

(In reply to Alex Limi (:limi) — Firefox UX Team from comment #21) > ... > We should change it to 400ms, and land this, as well as backport that change > in value to Aurora. No problem. (In reply to Timothy Nikkel (:tn) from comment #20) > On Windows it might depend on the specific hardware and driver in use, but > on Mac and Linux we never get pixel scroll events to scroll frames that ask > for smooth scrolling. Sounds like you've only changed the behavior for > (some subset of) Windows users. I think that mean that decision #2 from bug 206438 comment 62 invalid. Which means that on Linux/OSX we cannot distinguish mouse wheel events from the rest by looking at the unit type. - I think we should re-open bug 206438, since it appears that we've only affected windows. - Is there a method to identify mouse wheel events, without changing scrolling APIs?

400ms is still too long, especially for those used to the snappyiness of the old way.

(In reply to Alex Limi (:limi) — Firefox UX Team from comment #21) > We should change it to 400ms, and land this, as well as backport that change > in value to Aurora. As a slight correction, I talked with Alex offline and his feedback is only related to changing the duration of pixel scrolling to 400ms. We want to keep the duration of lines scrolling fixed to 150ms.

(In reply to Jared Wein [:jaws] from comment #24) > (In reply to Alex Limi (:limi) — Firefox UX Team from comment #21) > > We should change it to 400ms, and land this, as well as backport that change > > in value to Aurora. > > As a slight correction, I talked with Alex offline and his feedback is only > related to changing the duration of pixel scrolling to 400ms. We want to > keep the duration of lines scrolling fixed to 150ms. Yes, of course.

(In reply to Avi Halachmi (:avih) from comment #22) > - I think we should re-open bug 206438, since it appears that we've only > affected windows. I think we should only reopen it if we decide to back it out completely. Otherwise we should file new bugs for remaining issues. > - Is there a method to identify mouse wheel events, without changing > scrolling APIs? If there isn't we can probably add one.

(In reply to Danial Horton from comment #23) > 400ms is still too long, especially for those used to the snappyiness of the > old way. 150 min/max pixels seems better for me personally, though 400 is slight above my comfort level since I like fast and fluid most of the time.

(In reply to Timothy Nikkel (:tn) from comment #26) > I think we should only reopen it if we decide to back it out completely. > Otherwise we should file new bugs for remaining issues. > > > - Is there a method to identify mouse wheel events, without changing > > scrolling APIs? > > If there isn't we can probably add one. Fix for OSX+Linux mouse wheel identification is now handled at bug 737758.

(In reply to Avi Halachmi (:avih) from comment #29) > Created attachment 607884 [details] [diff] [review] > Changes default duration for "pixels" from to 800ms to 400ms Did you mean to request review for this?

Comment on attachment 607884 [details] [diff] [review] Changes default duration for "pixels" from to 800ms to 400ms Per comment 21, we should land the change to 400ms and close this bug.

or we should leave it open and wait for user response, which is the smarter, user friendly direction.

Comment on attachment 607884 [details] [diff] [review] Changes default duration for "pixels" from to 800ms to 400ms Review of attachment 607884 [details] [diff] [review]: ----------------------------------------------------------------- This patch is OK with me, but really needs ui-review, not technical review.

Comment on attachment 607884 [details] [diff] [review] Changes default duration for "pixels" from to 800ms to 400ms Looks good to me!

https://hg.mozilla.org/integration/mozilla-inbound/rev/c50d7ca7c23e To make life easier for those checking patches in for you, please follow the directions below for future patches. Thanks! https://developer.mozilla.org/en/Mercurial_FAQ#How_can_I_generate_a_patch_for_somebody_else_to_check-in_for_me.3F

Comment on attachment 607884 [details] [diff] [review] Changes default duration for "pixels" from to 800ms to 400ms And we're gonna want this on Aurora too, right?

Comment on attachment 607884 [details] [diff] [review] Changes default duration for "pixels" from to 800ms to 400ms [Aurora Approval Request Comment] Regression caused by (bug #): bug 206438 User impact if declined: difference in scrolling duration between Fx13 & Fx14 Testing completed (on m-c, etc.): tested locally, simple preference change Risk to taking this patch (and alternatives if risky): none String changes made by this patch: none

Comment on attachment 607884 [details] [diff] [review] Changes default duration for "pixels" from to 800ms to 400ms [Triage Comment] Very early in the cycle and we don't expect any regressions. Approved for Aurora 13.

Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20100101 Firefox/13.0 (beta4) Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20100101 Firefox/13.0 Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120520 Firefox/14.0a2 The default value of general.smoothScroll.pixels.durationMaxMS and general.smoothScroll.pixels.durationMinMS is 150, not 400, although smooth scrolling is enabled

That's odd; was this changed somewhere else? The patch in comment 40 definitely shows this was changed to 400 in Aurora.

It was changed with bug 737758. The new string is general.smoothScroll.mouseWheel.durationMax[/Min]MS .

Thanks Avi. Mihaela, can you please reconfirm with those details?

(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #44) > Thanks Avi. Mihaela, can you please reconfirm with those details? Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20100101 Firefox/13.0 Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20100101 Firefox/13.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20100101 Firefox/13.0 Confirming that: general.smoothScroll.mouseWheel.durationMinMS = 200 general.smoothScroll.mouseWheel.durationMaxMS = 400 Marking bug verified.