Closed Bug 829952 Opened 11 years ago Closed 11 years ago

Scrolling using some high-resolution-scroll aware touchpads feels slow

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

x86
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla22
Tracking Status
firefox19 --- wontfix
firefox20 - wontfix
firefox21 + wontfix
firefox22 --- fixed
relnote-firefox --- 22+

People

(Reporter: smaug, Assigned: masayuki)

References

Details

(Keywords: regression, Whiteboard: [snappy])

Attachments

(5 files, 3 obsolete files)

I tested Nightly on various Windows laptops (in a shop), and at least on some of them scrolling using *touchpad* felt slow. Could we do UX testing, and perhaps change the scrolling settings based on drivers or whatever is causing the slowness.
(This is *not* performance problem, but ux problem.)

Normally I don't use Windows, so my experience is close to first-time user.
There are several major trackpad/touchpad manufacturers and various drivers/config defaults that come with new PCs. Unlike the old simple trackpads, the devices shipping on Windows notebooks for the last couple of years have been larger and support multi-touch. Unfortunately, each vendor has a different idea about the various gestures. Two finger scrolling, being the most commonly encountered multi-touch gesture for most Windows notebook users, is somewhat inconsistent and it's certainly the first one we should tackle.

With several different hardware devices available from each of several different vendors, and no doubt with different driver versions and user options for most of them, how do we tackle the most important targets first? We'd need an inventory and some idea about popularity of the various combinations. Maybe by way of sales data from the major trackpad vendors, we could get some idea of which are most popular?

Is there any way to get this information directly from our users so we don't have to go to third parties or guess?

If we find that some significant populations of Firefox users are getting a scrolling behavior that feels much slower than others, this is probably snappy worthy.
Whiteboard: snappy?
toolkit.scrollbox.verticalScrollDistance=3 is the pref in about:config that determines how far the scrolling is moved, in combination with whatever the touchpad/mouse drivers have for how many lines to scroll for each scroll request.

We could increase the verticalScrollDistance pref if we feel that it will be a positive improvement.
(In reply to Asa Dotzler [:asa] from comment #1)
> Is there any way to get this information directly from our users so we don't
> have to go to third parties or guess?

I don't think that any survey we do would have the geographic scale to be representative, but I will verify with metrics.

I think we'd have to see what vendor detail is available - that might be expensive.  I'll find out.
Seems like most of Asus laptops for example suffer from this.
Changing mousewheel.delta.delta_multiplier_y from 100 to 250 gives more reasonable scrolling.
On an Asus laptop 
mousewheel.delta.delta_multiplier_y 250
mousewheel.min_line_scroll_amount 2
mousewheel.acceleration.factor 5
made scrolling feel significantly better.

But some UX folks should investigate this issue too.
(In reply to Olli Pettay [:smaug] from comment #5)
> On an Asus laptop 
> mousewheel.delta.delta_multiplier_y 250
> mousewheel.min_line_scroll_amount 2
> mousewheel.acceleration.factor 5
> made scrolling feel significantly better.
> 
> But some UX folks should investigate this issue too.

Which trackpad hardware and driver version do you have? I'd like to compare with a couple of Asus notebooks I have.
Asus PS/2 Port ClickPad
Driver v. 1.0.0.125
There seem to be some reports about this issue elsewhere and the solution people take is
"use some other browser".

I know very little about Windows widget level code, but could we somehow detect different kinds
of touchpads and use different default configs for some of them?
Historically, mouse driver is implemented hacky because Windows added new feature a couple of times and applications need to handle the new feature themselves. Actually, some mouse drivers change the native message by focused window class or active process name. So, we may not have any way to fix this bug. But anyway, we need the exact message log of such environment.

You can get the log with following envs:

NSPR_LOG_FILE=(path to log file)
NSPR_LOG_MODULES=MouseScrollHandlerWidgets:1
My friend just got Samsung ultrabook 5. I believe that is rather popular laptop.
Scrolling is horrible.
Settings from comment 5 make scrolling quite nice.
There are only a couple major trackpad vendors in the Windows ecosystem. I imagine the driver combinations make it a pretty big matrix but there may be common defaults across the hardware or possibly across major versions of drivers. 

Alternatively, is there some simple measurement we could do client side to use to set the value, perhaps during install time or shortly after first run? 

Also, what do other browsers do? Can someone look at Chrome and IE and see if they're doing a better job here?
Settings from comment 5 seem to give pretty much the same behavior what IE has.
Whiteboard: snappy? → [snappy]
(In reply to Asa Dotzler [:asa] from comment #11)
> Alternatively, is there some simple measurement we could do client side to
> use to set the value, perhaps during install time or shortly after first
> run? 

Users can switch pointing device anytime. So, we need to check the strange driver at every native event.

> Also, what do other browsers do? Can someone look at Chrome and IE and see
> if they're doing a better job here?

Chrome does always twice faster scroll on Windows. That was discussed for a couple of years ago. Then, we also use twice faster scroll only when both registry values (for vertical and horizontal) of scroll amount are not customized.

However, there is a possible thing. That is, the driver doesn't send strange value for other browsers. I suspect this. Therefore, I'd like to see the log mentioned in comment 9.
Trying to still figure out how to create the logs mentioned in comment 9.

I compared scrolling of www.hs.fi from bottom to top. On IE and Chrome it took about 14
"full touchpad scrolls", on Nightly 20. (Using Asus U500vz/Win8)
Attached file testcase
Or, you can check wheel event's delta values and delta mode. If the delta mode is DOM_DELTA_PIXEL, it uses gesture event.
Attached patch logSplinter Review
Hmm, 0.3 line is scrolled by each native event. And the system settings are default (3 lines/chars). So, the scrolling speed must be multiplied by 2 in ESM.

So, I have no idea why you feel this slow. How many times did you swipe the touchpad?
Ah, perhaps, the normal scroll speed which you think is overridden scroll speed. And the tested device isn't overridden the scroll speed by ESM.

http://mxr.mozilla.org/mozilla-central/source/content/events/src/nsEventStateManager.cpp#645

The device supports high-resolution scroll. Therefore, nsMouseWheelTransaction::OverrideSystemScrollSpeed() does nothing.
http://mxr.mozilla.org/mozilla-central/source/content/events/src/nsEventStateManager.cpp#645

I think that we should improve the mechanism for high resolution scrollable devices.
Assignee: nobody → masayuki
Component: General → Event Handling
Product: Firefox → Core
Version: unspecified → Trunk
Ah, of course :)

Can we detect whether the input is coming from a touchscreen or touchpad, since only the latter one
should get some acceleration.
I don't familiar with raw input. If it's possible, we need to handle raw input event, probably.

# Basically, acceleration is a job of such device driver.
This testcase works on all browsers (except for IE which doesn't display the gradient), records (hopefully) all related events, accumulates them, and displays the page position at the end of the scroll.

Here are my results after testing using this testcase on Nightly, Chrome, IE9 and Opera, with both a quick scroll, and a longer one.

System: Windows 7 home premium.
HW: Asus N56VZ, Elantech touchpad.

- All browsers allowed pixel-accurate vertical scroll with the touchpad.
- Firefox displays fractional line deltas for wheel.deltaY(DOM_DELTA_LINE)
- No browser displayed any horizontal event data,
    eventhough all browsers scrolled horizontally in "line" jumps.

In general, if Firefox scrolls X pixels for a top-to-bottom swipe of the touchpad, then, for the same swipe, on my system:

- Chrome scrolls ~1.7x
- IE9 scrolls ~6x
- Opera scrolls ~13x

Also, opera is the only browser which scrolled longer distance (consistently) on the slow swipe. All other browsers scrolled slightly shorter distance than the short swipe.

All the tests were repeated several times to make sure the results are relatively consistent.


Quick scroll: about 1000ms top to bottom
----------------------------------------

Nightly (22):
-------------
pageYOffset: 478
Accumulated:
Count: 114, Sum: 26.1, Event: wheel.deltaY(DOM_DELTA_LINE)
Count: 99, Sum: 406.0, Event: MozMousePixelScroll.detail(VERTICAL_AXIS)
Count: 26, Sum: 26.0, Event: DOMMouseScroll.detail(VERTICAL_AXIS)

Chrome (25.0...):
-----------------
pageYOffset: 819
Accumulated:
Count: 99, Sum: -988.0, Event: mousewheel.wheelDeltaY
Count: 99, Sum: -988.0, Event: mousewheel.wheelDelta

IE9:
----
pageYOffset: 2898
Accumulated:
Count: 24, Sum: 3644.0, Event: wheel.deltaY(DOM_DELTA_PIXEL)
Count: 24, Sum: -2592.0, Event: mousewheel.wheelDelta

Opera 12.11:
------------
pageYOffset: 6528
Accumulated:
Count: 103, Sum: 172.0, Event: mousewheel.detail
Count: 103, Sum: -6880.0, Event: mousewheel.wheelDeltaY
Count: 103, Sum: -6880.0, Event: mousewheel.wheelDelta


Slow scroll: about 3000ms top to bottom:
----------------------------------------

Nightly:
--------
pageYOffset: 389
Accumulated:
Count: 180, Sum: 21.1, Event: wheel.deltaY(DOM_DELTA_LINE)
Count: 155, Sum: 242.0, Event: MozMousePixelScroll.detail(VERTICAL_AXIS)
Count: 21, Sum: 21.0, Event: DOMMouseScroll.detail(VERTICAL_AXIS)

Chrome:
-------
pageYOffset: 686
Accumulated:
Count: 151, Sum: -826.0, Event: mousewheel.wheelDeltaY
Count: 151, Sum: -826.0, Event: mousewheel.wheelDelta

IE9:
----
pageYOffset: 2243
Accumulated:
Count: 40, Sum: 2807.0, Event: wheel.deltaY(DOM_DELTA_PIXEL)
Count: 40, Sum: -2016.0, Event: mousewheel.wheelDelta

Opera:
------
pageYOffset: 9473 (yes, it really did scroll that far)
Accumulated:
Count: 168, Sum: 246.0, Event: mousewheel.detail
Count: 168, Sum: -9840.0, Event: mousewheel.wheelDeltaY
Count: 168, Sum: -9840.0, Event: mousewheel.wheelDelta
This revised testcase has slightly prettier print, and also takes into account the scroll which happens after the last event (as happens with Smooth scroll). However, the results are within 5% of the previous variant of this testcase, the the previous results are still valid.

Also, for reference, I'm attaching a test run of this testcase using a proper mouse wheel (full "swipe" of the mouse wheel (with discrete notches) in a relatively medium steady speed).

Note that using the mouse wheel, the scroll distances are almost identical between browsers.

So indeed we have a slowness issue (on my system, as well) using the touchpad.


Results using one swipe of a mouse wheel with discrete notches:

Nightly:
--------
pageYOffset: 1596
Accumulated:
Count: 14, Sum: 42.0, Event: wheel.deltaY (deltaMode: DOM_DELTA_LINE)
Count: 14, Sum: 42.0, Event: DOMMouseScroll.detail (axis: VERTICAL_AXIS)
Count: 14, Sum: 798.0, Event: MozMousePixelScroll.detail (axis: VERTICAL_AXIS)

Chrome:
-------
pageYOffset: 1400
Accumulated:
Count: 14, Sum: -1680.0, Event: mousewheel.wheelDeltaY

IE9:
----
pageYOffset: 1863
Accumulated:
Count: 7, Sum: 2324.0, Event: wheel.deltaY (deltaMode: DOM_DELTA_PIXEL)
Count: 7, Sum: -1680.0, Event: mousewheel.wheelDelta

Opera:
------
pageYOffset: 1680
Accumulated:
Count: 14, Sum: 42.0, Event: mousewheel.detail
Count: 14, Sum: -1680.0, Event: mousewheel.wheelDeltaY
Count: 14, Sum: -1680.0, Event: mousewheel.wheelDelta
Attachment #717732 - Attachment is obsolete: true
i use a Dell inspiron N5010 with a Synaptic touchpad, Win7 x64.  In the touchpad drivers,I  adjust the acceleration and speed of scrolling using FF as the base. This has the result that Opera is extremely fast (unusable) , IE10 is fast, Chrome is almost like Firefox. (and of course, FF feels just OK )

Nightly 22 : 
-----------
pageYOffset: 29369
Accumulated:
Count: 69, Sum: 5511.5, Event: wheel.deltaY (deltaMode: DOM_DELTA_LINE)
Count: 69, Sum: 5511.0, Event: DOMMouseScroll.detail (axis: VERTICAL_AXIS)
Count: 69, Sum: 104702.0, Event: MozMousePixelScroll.detail (axis: VERTICAL_AXIS)


Chrome 25:
----------
pageYOffset: 29380
Accumulated:
Count: 43, Sum: -114113.0, Event: mousewheel.wheelDeltaY (deltaMode: DOM_DELTA_PIXEL)
Count: 43, Sum: -114113.0, Event: mousewheel.wheelDelta (deltaMode: DOM_DELTA_PIXEL)


Opera :
-------
pageYOffset: 29378
Accumulated:
Count: 36, Sum: 836.0, Event: mousewheel.detail
Count: 36, Sum: -33440.0, Event: mousewheel.wheelDeltaY
Count: 36, Sum: -33440.0, Event: mousewheel.wheelDelta

IE10:
------
 pageYOffset: 29350
Accumulated:
Count: 16, Sum: 39340.6, Event: wheel.deltaY (deltaMode: DOM_DELTA_PIXEL)
Count: 16, Sum: -80328.0, Event: mousewheel.wheelDelta
Here are some Linux-based results on a Dell XPS1645 (synaptic touchpad), Ubuntu 12.10 x64, radeonhd driver (free community-maintained, non-binaryblob). I didn't touch my mouse/touchpad settings. 1. Firefox feels extremely sluggish, 2. Chrome feels fast, Epiphany/Web feels a bit sluggish. Below are my results for http://avih.github.com/testcases/mozwheel-test-v4.html

UA: Mozilla/5.0 (X11; Linux x86_64; rv:21.0) Gecko/20130309 Firefox/21.0
-----------------
pageYOffset: 5415
Accumulated:
Count: 1995, Sum: 393.0, Event: wheel.deltaY (deltaMode: DOM_DELTA_LINE)
Count: 1919, Sum: 333.0, Event: DOMMouseScroll.detail (axis: VERTICAL_AXIS)
Count: 1919, Sum: 6327.0, Event: MozMousePixelScroll.detail (axis: VERTICAL_AXIS)
Count: 115, Sum: 97.0, Event: wheel.deltaX (deltaMode: DOM_DELTA_LINE)
Count: 116, Sum: 98.0, Event: DOMMouseScroll.detail (axis: HORIZONTAL_AXIS)
Count: 116, Sum: 980.0, Event: MozMousePixelScroll.detail (axis: HORIZONTAL_AXIS)

UA: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.28 Safari/537.31
-----------------
pageYOffset: 0
Accumulated:
Count: 13, Sum: 1560.0, Event: mousewheel.wheelDeltaY (deltaMode: DOM_DELTA_PIXEL)
Count: 731, Sum: -5160.0, Event: mousewheel.wheelDelta (deltaMode: DOM_DELTA_PIXEL)
Count: 74, Sum: -6720.0, Event: mousewheel.wheelDeltaX (deltaMode: DOM_DELTA_PIXEL)

UA: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.6+ (KHTML, like Gecko) Chromium/23.0.1271.95 Chrome/23.0.1271.95 Safari/537.6+ Ubuntu/12.10 (3.6.1-0ubuntu1) Epiphany/3.6.1
-----------------
pageYOffset: 0
Accumulated:
Count: 189, Sum: -10681.0, Event: mousewheel.wheelDeltaX
Count: 418, Sum: 10059.0, Event: mousewheel.wheelDeltaY
Count: 420, Sum: 9961.0, Event: mousewheel.wheelDelta
Status: NEW → ASSIGNED
Hardware: Other → x86
Attached patch Patch (obsolete) — Splinter Review
https://tbpl.mozilla.org/?tree=Try&usebuildbot=1&rev=da912014fb9b

I realized that OverrideSystemScrollSpeed() is now called very many times because we support higher resolution scrolling since D3E WheelEvent support.

Therefore, I guess that checking the prefs is not so cheap cost. I think that it's better to use Add*VarCache().
Attachment #724831 - Attachment is obsolete: true
Summary: Scrolling using touchpad feels slow on some laptops → Scrolling using some high-resolution-scroll aware touchpads feels slow
This must be a regression of bug 719320 (D3E WheelEvent).
Blocks: 719320
Keywords: regression
Comment on attachment 724842 [details] [diff] [review]
Patch

This regression is caused by my wrong decision. I assumed that high-resolution support pointing devices set good scroll speed and have their own acceleration system.

However, actually, the logged environment supports high resolution scroll but the user feels the speed slow.

So, I think that when pointing device doesn't customize the scrolling speed, we should always use "system scroll speed override".

And for reducing the run time cost of calls nsIWidget::OverrideSystemMouseScrollSpeed(), we should redesign its arguments for D3E WheelEvent. And now, we support higher resolution scroll before implementing D3E WheelEvent. Therefore, OverrideSystemMouseScrollSpeed() is called higher frequently. So, I think that we should cache the pref values into static variables.
Attachment #724842 - Flags: superreview?(roc)
Attachment #724842 - Flags: review?(roc)
Attachment #724842 - Flags: review?(bugs)
FYI: Logitech mouse driver, SetPoint 6.5 uses too high resolution scroll. Therefore, I believe that wheel event handler should reduce run time cost as far as possible.
(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #30)
> FYI: Logitech mouse driver, SetPoint 6.5 uses too high resolution scroll.
> Therefore, I believe that wheel event handler should reduce run time cost as
> far as possible.

Interesting. I've been having a problem where clicking on a click-to-play plugin element changes the number of lines scrolled per mousewheel increment (from 6 to 3) with my Logitech MX Revolution mouse.
Note that I'm not sure if this regression fix will satisfy all of them who complained about this in this bug. If they will still feel slow after landing the patch, let's separate it to another bug.
(In reply to timbugzilla from comment #31)
> (In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #30)
> > FYI: Logitech mouse driver, SetPoint 6.5 uses too high resolution scroll.
> > Therefore, I believe that wheel event handler should reduce run time cost as
> > far as possible.
> 
> Interesting. I've been having a problem where clicking on a click-to-play
> plugin element changes the number of lines scrolled per mousewheel increment
> (from 6 to 3) with my Logitech MX Revolution mouse.

SetPoint checks the scroll target window before sending wheel events. Therefore, when plugin window has focus, it probably doesn't use high resolution scroll. And the 3 is probably the correct scroll amount. 6 is the result of overridden by our "system scroll speed override".
https://wiki.mozilla.org/Gecko:Mouse_Wheel_Scrolling#Override_system_of_system_scroll_speed
Comment on attachment 724842 [details] [diff] [review]
Patch


> DeltaValues
> nsMouseWheelTransaction::OverrideSystemScrollSpeed(widget::WheelEvent* aEvent)
> {
>   MOZ_ASSERT(sTargetFrame, "We don't have mouse scrolling transaction");
>   MOZ_ASSERT(aEvent->deltaMode == nsIDOMWheelEvent::DOM_DELTA_LINE);
> 
>-  DeltaValues result(aEvent);
>+  DeltaValues originalDeltaValues(aEvent);
> 
>   // If the event doesn't scroll to both X and Y, we don't need to do anything
>-  // here.  And also, if the event indicates the device supports high
>-  // resolution scroll, we shouldn't need to override it.
>-  if ((!aEvent->lineOrPageDeltaX && !aEvent->lineOrPageDeltaY) ||
>-      (static_cast<double>(aEvent->lineOrPageDeltaX) != aEvent->deltaX) ||
>-      (static_cast<double>(aEvent->lineOrPageDeltaY) != aEvent->deltaY)) {
>-    return result;
>+  // here.
>+  if (!aEvent->deltaX && !aEvent->deltaY) {
>+    return originalDeltaValues;
>   }
Does returning aEvent here not work? DeltaValues has the right kind of ctor, so I'd assume it should work.

> 
>   // We shouldn't override the scrolling speed on non root scroll frame.
>   if (sTargetFrame !=
>         sTargetFrame->PresContext()->PresShell()->GetRootScrollFrame()) {
>-    return result;
>+    return originalDeltaValues;
>   }
Same here. But if not, this code is ok too.


>+  NS_ENSURE_TRUE(widget, originalDeltaValues);
>+  DeltaValues overriddenDeltaValues(0.0, 0.0);
>+  nsresult rv =
>+    widget->OverrideSystemMouseScrollSpeed(aEvent->deltaX, aEvent->deltaY,
>+                                           overriddenDeltaValues.deltaX,
>+                                           overriddenDeltaValues.deltaY);
>+  return NS_FAILED(rv) ? originalDeltaValues : overriddenDeltaValues;
If returning aEvent worked, this would become
return NS_FAILED(rv) ? DeltaValues(originalDeltaValues) : overriddenDeltaValues;

>+nsWindow::OverrideSystemMouseScrollSpeed(double aOriginalDeltaX,
>+                                         double aOriginalDeltaY,
>+                                         double &aOverriddenDeltaX,
>+                                         double &aOverriddenDeltaY)
Not sure about the coding style in this file, but usually
double& aFoo

>+nsBaseWidget::OverrideSystemMouseScrollSpeed(double aOriginalDeltaX,
>+                                             double aOriginalDeltaY,
>+                                             double &aOverriddenDeltaX,
>+                                             double &aOverriddenDeltaY)
ditto
Attachment #724842 - Flags: review?(bugs)
Attachment #724842 - Flags: review+
Attachment #724842 - Flags: feedback?(avihpit)
Nominating for tracking because this is a recent user-facing regression (introduced in Firefox 17).
Comment on attachment 724842 [details] [diff] [review]
Patch

Looks good as far as I can tell.
Attachment #724842 - Flags: feedback?(avihpit) → feedback+
(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #33)
> (In reply to timbugzilla from comment #31)
> > (In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #30)
> > > FYI: Logitech mouse driver, SetPoint 6.5 uses too high resolution scroll.
> > > Therefore, I believe that wheel event handler should reduce run time cost as
> > > far as possible.
> > 
> > Interesting. I've been having a problem where clicking on a click-to-play
> > plugin element changes the number of lines scrolled per mousewheel increment
> > (from 6 to 3) with my Logitech MX Revolution mouse.
> 
> SetPoint checks the scroll target window before sending wheel events.
> Therefore, when plugin window has focus, it probably doesn't use high
> resolution scroll. And the 3 is probably the correct scroll amount. 6 is the
> result of overridden by our "system scroll speed override".
> https://wiki.mozilla.org/Gecko:
> Mouse_Wheel_Scrolling#Override_system_of_system_scroll_speed

Thanks for the analysis of this - is there anything that can be done?
Attached patch PatchSplinter Review
Thank you, smaug and avih!
Attachment #724842 - Attachment is obsolete: true
Attachment #724842 - Flags: superreview?(roc)
Attachment #724842 - Flags: review?(roc)
Attachment #725207 - Flags: superreview?(roc)
Attachment #725207 - Flags: review?(roc)
Attachment #725207 - Flags: superreview?(roc)
Attachment #725207 - Flags: superreview+
Attachment #725207 - Flags: review?(roc)
Attachment #725207 - Flags: review+
When this lands, will we have to recaliberate the acceleration of the touchpads ?
Thank you roc.
https://hg.mozilla.org/integration/mozilla-inbound/rev/d0df4c867df8

(In reply to mayankleoboy1 from comment #39)
> When this lands, will we have to recaliberate the acceleration of the
> touchpads ?

Depends on the system settings. See https://wiki.mozilla.org/Gecko:Mouse_Wheel_Scrolling#Override_system_of_system_scroll_speed
Too close to FF20's release to take a touchpad fix, but we'll track for FF21.
https://hg.mozilla.org/mozilla-central/rev/d0df4c867df8
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla22
(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #40)
> Thank you roc.
> https://hg.mozilla.org/integration/mozilla-inbound/rev/d0df4c867df8
> 
> (In reply to mayankleoboy1 from comment #39)
> > When this lands, will we have to recaliberate the acceleration of the
> > touchpads ?
> 
> Depends on the system settings. See
> https://wiki.mozilla.org/Gecko:
> Mouse_Wheel_Scrolling#Override_system_of_system_scroll_speed

Can you please request approval nomination with risk analysis to uplift this on aurora, looks like its fixed on m-c now ? Thanks !
Indeed, however, I'd like somebody verify the fix on some laptops before request.
/me reboots this laptop in a minute to test behavior on Win8.
At least on this Asus U500vz Nightlies feel now good.
On my system new Nightlies now scroll with 2x distance for touchpad scroll, compared to before this patch. To me it feels better than before and good in general. It's now about 60% faster than Chrome (25), and about on par with IE10.
Thank you, guys.
# IIRC, Google Chrome doesn't aware with high resolution scroll event.
Attached patch Patch for AuroraSplinter Review
I merged the patch by my hands. I'll test it.
# Unfortunately, tomorrow is a national holiday of Japan, so, I'm not sure if I can check it tomorrow.
Comment on attachment 726673 [details] [diff] [review]
Patch for Aurora

[Approval Request Comment]
Bug caused by (feature/regressing bug #):
Bug 719320

User impact if declined:
Some users feel the scroll speed on root scrollable element slower than Fx16 or earlier.

Testing completed (on m-c, etc.):
The patch was already landed on m-c last week.

Risk to taking this patch (and alternatives if risky): 
Some other users might feel too fast the scroll speed by the system scroll override. Although, they can disable this feature with about:config:
mousewheel.system_scroll_override_on_root_content.enabled

String or UUID changes made by this patch: 
This needs the change of nsIWidget, which causes UUID change of it.
Attachment #726673 - Flags: approval-mozilla-aurora?
(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #50)
> Comment on attachment 726673 [details] [diff] [review]
> Patch for Aurora
> 
> [Approval Request Comment]
> Bug caused by (feature/regressing bug #):
> Bug 719320
> 
> User impact if declined:
> Some users feel the scroll speed on root scrollable element slower than Fx16
> or earlier.
> 
> Testing completed (on m-c, etc.):
> The patch was already landed on m-c last week.
> 
> Risk to taking this patch (and alternatives if risky): 
> Some other users might feel too fast the scroll speed by the system scroll
> override.

 Although, they can disable this feature with about:config:
> mousewheel.system_scroll_override_on_root_content.enabled
> 
> String or UUID changes made by this patch: 
> This needs the change of nsIWidget, which causes UUID change of it.

Given the risk , limited testing this has got and considering we are a couple of days away from the merge, this patch is almost hitting our beta audience directly without enough aurora population experiencing it.

Considering this issue is been there since Fx17 I think we should maintain the status quo for one more cycle in this case to avoid any unforeseen regressions this may cause due to so many different hardware configurations out there. wdyt ?
Excuse me, I don't know what means "wdyt".

Unfortunately, we don't have much time for next merge. So, I recommend to take this to aurora *not* strongly. If you worry the risk, it's also a good choice for risk management. This bug fix might kill better UX with the higher scrolling speed. So, the risk isn't so low.
(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #52)
> Excuse me, I don't know what means "wdyt".

Sorry about the slang here just meant to ask your opinion here (what do you think - WDYT) :)
> 
> Unfortunately, we don't have much time for next merge. So, I recommend to
> take this to aurora *not* strongly. If you worry the risk, it's also a good
> choice for risk management. This bug fix might kill better UX with the
> higher scrolling speed. So, the risk isn't so low.

Considering we are in the end of aurora cycle and based on the outlined risk letting this ride the trains instead of uplift here.
Attachment #726673 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora-
(In reply to bhavana bajaj [:bajaj] from comment #53)
> (In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #52)
> > Excuse me, I don't know what means "wdyt".
> 
> Sorry about the slang here just meant to ask your opinion here (what do you
> think - WDYT) :)

Thank you, such English knowledge helps me.

> > 
> > Unfortunately, we don't have much time for next merge. So, I recommend to
> > take this to aurora *not* strongly. If you worry the risk, it's also a good
> > choice for risk management. This bug fix might kill better UX with the
> > higher scrolling speed. So, the risk isn't so low.
> 
> Considering we are in the end of aurora cycle and based on the outlined risk
> letting this ride the trains instead of uplift here.

Okay, I agree with you. Thank you for the judge.
relnote-firefox: --- → ?
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.