New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 227454 link

Starred by 13 users

Issue metadata

Status: Fixed
Owner:
Email to this user bounced
Closed: Aug 2013
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Feature

Blocking:
issue 347562



Sign in to add a comment

Implement DOM3 wheel event

Reported by m.go...@gmail.com, Apr 7 2013

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.43 Safari/537.31

Steps to reproduce the problem:
Both Firefox and IE>=9 support the standardized DOM3 `wheel` event. WebKit (and now Blink) are the inly significant engines that haven't adopted it yet, forcing web developers to use polyfills utilizing the non-standard `mousewheel` event.

The problem is, the `wheel` event has different semantics from `mousewheel`, it supports various `deltaMode`s which influence its `deltaX`, `deltaY` and `deltaZ` fields. `mousewheel` has `wheelDelta`, `wheelDeltaX` & `wheelDeltaY`.

This issue was originally reported to WebKit: https://bugs.webkit.org/show_bug.cgi?id=94081

What is the expected behavior?

What went wrong?
The `wheel` event is not supported.

Did this work before? No 

Chrome version: 28.0.1468.0  Channel: canary
OS Version: OS X 10.8.3
 
Labels: Needs-Feedback
Can you please mention the issue with clear repro steps so that it would be helpful for us to further triage.

Comment 2 by m.go...@gmail.com, May 13 2013

I'm not sure what steps do you expect from me, this is a standards implementation request...

The `wheel` event has (amongst others) the following fields:
- deltaX: - horizontal delta
- deltaY: - vertical delta
- deltaZ: - 3rd dimension delta (0 in most cases)
- deltaMode: 0, 1 or 2 (mode 0 means deltas are computed in pixels, 1 in lines, 2 in pages)

In contrast, the `mousewheel` event doesn't have either of these fields but has:
- wheelDeltaX - horizontal delta in pixels
- wheelDeltaY - vertical delta in pixels
- wheelDelta - maximum of those two

Not all browsers supporting the `mousewheel` event support wheelDeltaX / wheelDeltaY. Besides, this event is non-standard and not supported by Firefox. The wheel event is defined in W3C specification:
http://www.w3.org/TR/DOM-Level-3-Events/#events-wheelevents
which is yet another reson to implement it.

Currently the `wheel` event is supported everywhere besides WebKit & Blink.

Do you need some other info from me?

Comment 3 by dtoybo...@gmail.com, Jul 18 2013

Hello, I'm the implementer of D3E WheelEvent on Gecko.

I researched legacy mousewheel event on all browsers. Then, I realized that the behavior of Chromium on Mac is very annoying for web developers. Chromium changes the wheelDelta computation, which depends on whether the event is caused by continuous scroll supported device or not.
https://developer.mozilla.org/en-US/docs/DOM/DOM_event_reference/mousewheel#wheelDelta.2C_wheelDeltaX_and_wheelDeltaY_value

Therefore, if Blink supports D3E wheel event, it's very helpful for web developers. Because Safari's wheelDelta value of legacy mousewheel always indicates scroll amount like D3E wheel event, it's useful only on Safari. 
Cc: adlr@chromium.org
Labels: -Cr-Content-JavaScript -Type-Bug -OS-Mac -Needs-Feedback Cr-Blink-Events Type-Feature CR-UI-Input-Touch-Screen
Status: Available
I agree we should add support for 'wheel'.  IE9+ and Firefox already support it, time for Blink to get on board too.  I'll see if I can find someone to pick it up and start an 'intent-to-implement' thread on blink-dev.
Labels: -CR-UI-Input-Touch-Screen Cr-UI-Input-Touch-Pad
Labels: Cr-IO-Mouse

Comment 7 by rbyers@chromium.org, Aug 16 2013

 Issue 273395  has been merged into this issue.

Comment 8 by rbyers@chromium.org, Aug 16 2013

Cc: dglazkov@chromium.org
Owner: ch.du...@samsung.com
Status: Assigned
Project Member

Comment 9 by bugdroid1@chromium.org, Aug 20 2013

The following revision refers to this bug:
    http://src.chromium.org/viewvc/blink?view=rev&rev=156404

------------------------------------------------------------------------
r156404 | ch.dumez@sisa.samsung.com | 2013-08-20T19:06:46.056063Z

Changed paths:
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/events/wheelevent-basic.html?r1=156404&r2=156403&pathrev=156404
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/html/HTMLElement.cpp?r1=156404&r2=156403&pathrev=156404
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/svg/SVGElementInstance.idl?r1=156404&r2=156403&pathrev=156404
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/page/DOMWindow.cpp?r1=156404&r2=156403&pathrev=156404
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/dom/Document.idl?r1=156404&r2=156403&pathrev=156404
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/events/wheelevent-constructor.html?r1=156404&r2=156403&pathrev=156404
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/dom/WheelEvent.cpp?r1=156404&r2=156403&pathrev=156404
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/page/DOMWindow.h?r1=156404&r2=156403&pathrev=156404
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/events/wheelevent-mousewheel-interaction.html?r1=156404&r2=156403&pathrev=156404
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/dom/EventNames.h?r1=156404&r2=156403&pathrev=156404
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/dom/WheelEvent.h?r1=156404&r2=156403&pathrev=156404
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/events/wheelevent-basic-expected.txt?r1=156404&r2=156403&pathrev=156404
   M http://src.chromium.org/viewvc/blink/trunk/Source/web/WebInputEventConversion.cpp?r1=156404&r2=156403&pathrev=156404
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/svg/SVGElementInstance.cpp?r1=156404&r2=156403&pathrev=156404
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/dom/Element.idl?r1=156404&r2=156403&pathrev=156404
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/events/wheelevent-constructor-expected.txt?r1=156404&r2=156403&pathrev=156404
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/dom/Document.h?r1=156404&r2=156403&pathrev=156404
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/svg/SVGElementInstance.h?r1=156404&r2=156403&pathrev=156404
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/events/wheelevent-mousewheel-interaction-expected.txt?r1=156404&r2=156403&pathrev=156404
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/dom/Node.cpp?r1=156404&r2=156403&pathrev=156404
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/html/HTMLAttributeNames.in?r1=156404&r2=156403&pathrev=156404
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/dom/EventTarget.cpp?r1=156404&r2=156403&pathrev=156404
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/html/shadow/SpinButtonElement.cpp?r1=156404&r2=156403&pathrev=156404
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/page/Window.idl?r1=156404&r2=156403&pathrev=156404
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/dom/WheelEvent.idl?r1=156404&r2=156403&pathrev=156404
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/dom/Element.h?r1=156404&r2=156403&pathrev=156404

Add support for DOM Level 3 WheelEvent

Add support for DOM Level 3 WheelEvent:
http://www.w3.org/TR/DOM-Level-3-Events/#events-WheelEvent

Full support is implemented except for the DeltaZ property which had
no equivalent in the previous 'mousewheel' event.

Firefox and IE10 already support it so it increases our cross-browser
compatibility.

The non-standard 'mousewheel' event is still supported for backward
compatibility.

BUG= 227454 

Review URL: https://chromiumcodereview.appspot.com/22859012
------------------------------------------------------------------------
Does anyone know in which case deltaZ is used?

I initially thought that it was related to zooming. However, pressing CTRL while using the wheel has no effect on deltaZ (tested on FF23 and IE10).

Comment 11 by m.go...@gmail.com, Aug 21 2013

Here's the spec: http://www.w3.org/TR/DOM-Level-3-Events/#events-WheelEvent-deltaZ

IMHO the spec is just ridiculously forward-thinking, deltaZ would make sense only on user agents displaying sites in 3D...

It just should be hardcoded to 0 in Blink for compatibility.
Only Mac has delta value along z-axis, however, Gecko always sets 0 for it because the sign of the value isn't clear.

http://mxr.mozilla.org/mozilla-central/source/widget/cocoa/nsChildView.mm?rev=d232d5d67b92#4824

I think Blink should not set it until new device supports it.

Comment 13 by m.go...@gmail.com, Aug 21 2013

Blink has to set it to 0, spec requires deltaZ to be 0 if scrolling along the z-axis is not supported.
This is already the case. Blink sets deltaZ to 0 for wheel events constructed on native side. deltaZ can be non-zero only if constructed on JS side using the WheelEventInit dictionary.

However, dtoybox69 noticed that we are using the wrong sign for deltaY. deltaY should be positive when scrolling down as per the spec (also matches FF and IE). However, my patch uses the same value as mouseWheelY which is negative in this case.

I will address this issue asap.
> However, dtoybox69 noticed that we are using the wrong sign for deltaY. deltaY should be positive when scrolling down as per the spec (also matches FF and IE). However, my patch uses the same value as mouseWheelY which is negative in this case.

And IIRC, on Windows, Linux and Mac with non-continuous scroll supported mouse, the wheelDeltaX/Y values are not scroll amount in pixels on Blink. If so, your patch returns wrong deltaX/Y on both of them. Please check it.

In my understanding, the wheelDeltaX/Y indicates physical wheel turned amount on IE and Blink.
Project Member

Comment 16 by bugdroid1@chromium.org, Aug 21 2013

The following revision refers to this bug:
    http://src.chromium.org/viewvc/blink?view=rev&rev=156478

------------------------------------------------------------------------
r156478 | ch.dumez@sisa.samsung.com | 2013-08-21T17:02:59.420141Z

Changed paths:
   M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/events/wheelevent-basic.html?r1=156478&r2=156477&pathrev=156478
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/dom/WheelEvent.cpp?r1=156478&r2=156477&pathrev=156478
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/html/shadow/SpinButtonElement.cpp?r1=156478&r2=156477&pathrev=156478
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/dom/WheelEvent.h?r1=156478&r2=156477&pathrev=156478

WheelEvent's deltaX/deltaY sign is wrong

According to the specification, if a user agent scrolls as the default action
of the wheel event then the sign of the delta should be given by a right-hand
coordinate system where positive X, Y, and Z axes are directed towards the
right-most edge, bottom-most edge, and farthest depth (away from the user) of
the document, respectively:
http://www.w3.org/TR/DOM-Level-3-Events/#events-wheelevents

This signs for deltaX/deltaY are the inversed compared to the legacy
wheelDeltaX/wheelDeltaY. r156404 added support for DOM3 WheelEvent but used
the same sign for deltaX/deltaY and wheelDeltaX/wheelDeltaY.

Firefox 23 and IE10 uses the right sign according to the specification.

BUG= 227454 

Review URL: https://chromiumcodereview.appspot.com/22888005
------------------------------------------------------------------------
Cc: arv@chromium.org
dtoybox69, on Blink, the delta is currently computed by multiplying the number of mouse wheel ticks turned by 120 (so one wheel tick down gives you a deltaY of +120.0 pixels). This is currently the same for wheel and mousewheel events (except for the sign and floating point precision).

arv already proposed that we report as delta the exact amount of pixels scrolled, similarly to IE. I still need to investigate this.

We gave Firefox 23 a try but it was reporting deltas in lines, not pixels.
Project Member

Comment 18 by bugdroid1@chromium.org, Aug 21 2013

The following revision refers to this bug:
    http://src.chromium.org/viewvc/blink?view=rev&rev=156500

------------------------------------------------------------------------
r156500 | ch.dumez@sisa.samsung.com | 2013-08-21T20:42:29.396771Z

Changed paths:
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/events/wheelevent-document-createevent.html?r1=156500&r2=156499&pathrev=156500
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/dom/WheelEvent.cpp?r1=156500&r2=156499&pathrev=156500
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/events/wheelevent-document-createevent-expected.txt?r1=156500&r2=156499&pathrev=156500

WheelEvent created using document.createEvent() is not properly initialized

WheelEvent created using document.createEvent() is not properly initialized,
its deltaX, deltaY, deltaZ attributes are uninitialized. The specification
indicates that those should be initialized to 0.

R=arv
BUG= 227454 

Review URL: https://chromiumcodereview.appspot.com/23381002
------------------------------------------------------------------------
I confirmed that on Windows, Blink always set 120 or -120 per notch of mouse wheel. However, I change the scroll amount per notch in system settings, the scroll amount is changed as expected (except at 3 lines, though) but the wheelDelta values are still 120 or -120. So, there is no relation between scroll amount and wheelDelta value.

> We gave Firefox 23 a try but it was reporting deltas in lines, not pixels.

Yes, it's the best approach on Windows because on Windows, mouse wheel scroll amount is computed to amount of lines or amount of pages (like 3 lines, 0.5 lines, 1 page, 0.3pages).

If mouse wheel doesn't support continuous scroll on Mac, the native event also indicate scroll amount in lines.
Project Member

Comment 20 by bugdroid1@chromium.org, Aug 23 2013

The following revision refers to this bug:
    http://src.chromium.org/viewvc/blink?view=rev&rev=156603

------------------------------------------------------------------------
r156603 | ch.dumez@sisa.samsung.com | 2013-08-23T00:45:20.217590Z

Changed paths:
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/dom/WheelEvent.cpp?r1=156603&r2=156602&pathrev=156603
   M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/events/wheelevent-basic-expected.txt?r1=156603&r2=156602&pathrev=156603
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/dom/WheelEvent.h?r1=156603&r2=156602&pathrev=156603
   M http://src.chromium.org/viewvc/blink/trunk/Source/web/WebInputEventConversion.cpp?r1=156603&r2=156602&pathrev=156603
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/page/EventHandler.cpp?r1=156603&r2=156602&pathrev=156603
   M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/events/wheelevent-basic.html?r1=156603&r2=156602&pathrev=156603

WheelEvent's deltaX/deltaY should report real amount of pixels scrolled

As per the specification, the DOM3 WheelEvent's deltaX/deltaY should report
the real amount of pixels scrolled. This is also the way IE and Firefox
behave.

However, Blink was reporting the number of mouse wheel ticks multiplied
by a multiplier (120) which does not necessarily match the real amount
of pixels that is scrolled.

R=arv
BUG= 227454 

Review URL: https://chromiumcodereview.appspot.com/23034006
------------------------------------------------------------------------
Status: Fixed
The implementation seems complete. Please let me know if I overlooked anything or if issues come up.
Will the "wheel" event provide delta value in "lines" units on Windows, like Firefox does?
I am a contributor of ACE editor (ajax.ace.org), and I need to get delta in lines (when available) rather than in pixels.
Firefox uses DOM_DELTA_LINE unit on Windows for reqular mouse, so there is no problem in that browser. But for legacy "mousewheel" event I have to convert deltas to the lines (https://github.com/danyaPostfactum/ace/blob/7d1fe36ae153fadedd0b5b0566f55af8f5679e7b/lib/ace/lib/event.js#L142). And that's not good, especially because of there are some kind of input devices, maybe on other platforms, providing deltas in PIXELs, so the blind conversion to lines is not correct.
I think you should consider this information (taken from https://developer.mozilla.org/en-US/docs/Web/Reference/Events/wheel) :
On Windows, following 3 native events cause DOM wheel events.

WM_MOUSEWHEEL (Vertical mouse wheel event)
The deltaMode can be DOM_DELTA_LINE or DOM_DELTA_PAGE. It depends on user settings of Windows (The defualt setting causes DOM_DELTA_LINE).
WM_MOUSEHWHEEL (Horizontal mouse wheel event)
The deltaMode can be DOM_DELTA_LINE or DOM_DELTA_PAGE. However, neither wheel scroll speed setting dialog of Windows nor similar UI of each mouse driver's utility typically has the UI to change to page scroll. So, typically, this value is DOM_DELTA_LINE.
WM_GESTURE (Only when caused by panning)
The deltaMode is always DOM_DELTA_PIXEL. But note that most touchpad devices of notebook emulate mouse wheel events rather than using this event. This event it typically used on tablet PC.
On Mac, deltaMode value depends on the device. If the device supports high resolution scroll by pixels, deltaMode value is typically DOM_DELTA_PIXEL. 

Comment 23 by arv@chromium.org, Aug 30 2013

We ended up doing what IE does and report the exact number of pixels we would scroll the element.

The following asserts are always true (given that the element can be scrolled).

element.scrollTop = 0;
element.addEventListener('wheel', function(e) {
  assert(e.deltaMode === MouseEvent. DOM_DELTA_PIXEL);
  assert(element.scrollTop === e.deltaY);
});
// scroll

This way you know exactly how much to scroll at all times.

We never set the deltaMode to anything else but DOM_DELTA_PIXEL.
How can I get lines amout for mouse wheel (in Windows and Linux) and pixels amount for high-resolution input device?
What is the reason for converting lines to pixels on mentioned platforms?
Firefox and Opera (Presto) provides delta in lines, and this is more useful I think.
It could be useful for proper scrolling in code editors, table grids with virtual view etc.
If web developer needs pixels value, he anyway needs to convert lines amount (and pages amount) to pixels.
But if he needs lines number, what should he do?

Comment 25 by Deleted ...@, Sep 2 2013

> This way you know exactly how much to scroll at all times.

Ideally, the delta value shouldn't be computed to pixel amount if the system event indicates line scroll amount or page scroll amount because the line-height or page-height/width which is used for computing the scroll amount in pixels depends on the "rule" of the browser. In other words, web application cannot use their own rules for computing scroll amount in their own widget.

And if you see your idea from another angle, the wheel event is notification of just scroll amount on the browser. I.e., it isn't notification of how much the user wanted to scroll.

Comment 26 by adlr@chromium.org, Sep 10 2013

For those asking for line scroll amounts, keep in mind that on many Chrome platforms (at least Mac, Android, and Chrome OS), touchpads and touchscreens generate very precise scroll amounts in terms of pixels, and the amount a text buffer scrolls should be the same as any other surface. For example, it would be odd if when scrolling with a touchscreen, the content didn't stay stuck to the finger.
> For those asking for line scroll amounts, keep in mind ...
I know that. It's ok. I want lines when OS provides lines. I want pixels if OS provides pixels.
And Firefox does exactly what I need. So, in Firefox, my app always suits user OS and behaves as user expects. Unfortunately it will not work properly in Chrome due to forced line2pixel builtin conversion..
Blocking: chromium:289887

Comment 29 by adlr@chromium.org, Sep 26 2013

I don't know about Windows, but on Chrome OS (and likely Mac), the mouse wheel provides pixel scroll amounts from the OS to Chrome. This is b/c the OS does scroll wheel acceleration, so slow scrolls move less than fast scrolls. The OS layer finds it easier to send pixel values when doing acceleration.

I don't know if Windows does scroll wheel acceleration. Maybe this bug should be Windows only?

Side note: weird that rbyers marked this a blocker when this bug is already marked Fixed.
Labels: -Cr-UI-Input-Touch-Pad Cr-Internals-Input-Touch-Pad
Blocking: chromium:347562
Blocking: -chromium:289887

Sign in to add a comment