Add support for DOM Level 3 WheelEvent

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
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=156404

[arv (Not doing code reviews), 2013-08-15 14:05:44]

https://codereview.chromium.org/22859012/diff/4001/LayoutTests/fast/events/wh...
File LayoutTests/fast/events/wheelevent-basic.html (right):

https://codereview.chromium.org/22859012/diff/4001/LayoutTests/fast/events/wh...
LayoutTests/fast/events/wheelevent-basic.html:13:
shouldBe('WheelEvent.__proto__', 'MouseEvent');
Also

shouldBe('WheelEvent.prototype.__proto__', 'MouseEvent.prototype');

https://codereview.chromium.org/22859012/diff/4001/LayoutTests/fast/events/wh...
LayoutTests/fast/events/wheelevent-basic.html:14:
shouldBe('WheelEvent.DOM_DELTA_PIXEL', '0x00');
Can't believe we are adding more numeric constants :'(

https://codereview.chromium.org/22859012/diff/4001/LayoutTests/fast/events/wh...
LayoutTests/fast/events/wheelevent-basic.html:34: var expectedDeltaX = deltaX *
tickMultiplier;
The main issues historically have been that the deltas have been different
between browsers. Can we make sure we are fully aligned this time around?

https://codereview.chromium.org/22859012/diff/4001/LayoutTests/fast/events/wh...
LayoutTests/fast/events/wheelevent-basic.html:42:
shouldBeUndefined("testEvent.deltaZ"); // Not supported yet.
Would it be better to return 0 here for now? What does other browsers return for
non z capable scroll wheels?

https://codereview.chromium.org/22859012/diff/4001/LayoutTests/fast/events/wh...
File LayoutTests/fast/events/wheelevent-constructor.html (right):

https://codereview.chromium.org/22859012/diff/4001/LayoutTests/fast/events/wh...
LayoutTests/fast/events/wheelevent-constructor.html:5: <script
src="../js/resources/js-test-pre.js"></script>
I really wish we would use the testharness.js for new tests like these. Would
make it easier to upstream tests to w3c. Let me start a thread on blink-dev@

https://codereview.chromium.org/22859012/diff/4001/Source/core/dom/Document.idl
File Source/core/dom/Document.idl (right):

https://codereview.chromium.org/22859012/diff/4001/Source/core/dom/Document.i...
Source/core/dom/Document.idl:202: [NotEnumerable, PerWorldBindings,
ActivityLog=SetterForIsolatedWorlds] attribute EventHandler onmousewheel; //
Deprecated in favor of onwheel.
Remember to file a tracking bug so we can clean this up in a few months.

https://codereview.chromium.org/22859012/diff/4001/Source/core/dom/WheelEvent...
File Source/core/dom/WheelEvent.idl (right):

https://codereview.chromium.org/22859012/diff/4001/Source/core/dom/WheelEvent...
Source/core/dom/WheelEvent.idl:37: [InitializedByEventConstructor,
ImplementedAs=deltaX] readonly attribute long wheelDeltaX;
OK. I see, we use the same interface... this should also be deprecated when we
deprecate onmousewheel.

[do-not-use, 2013-08-16 09:57:16]

https://codereview.chromium.org/22859012/diff/4001/Source/core/dom/WheelEvent...
File Source/core/dom/WheelEvent.idl (right):

https://codereview.chromium.org/22859012/diff/4001/Source/core/dom/WheelEvent...
Source/core/dom/WheelEvent.idl:31: [InitializedByEventConstructor] readonly
attribute long deltaX;
These should be "double", not "long". I'll fix this in the next iteration as
well.

[do-not-use, 2013-08-16 12:02:49]

https://codereview.chromium.org/22859012/diff/4001/LayoutTests/fast/events/wh...
File LayoutTests/fast/events/wheelevent-basic.html (right):

https://codereview.chromium.org/22859012/diff/4001/LayoutTests/fast/events/wh...
LayoutTests/fast/events/wheelevent-basic.html:13:
shouldBe('WheelEvent.__proto__', 'MouseEvent');
On 2013/08/15 14:05:44, arv wrote:
> Also
> 
> shouldBe('WheelEvent.prototype.__proto__', 'MouseEvent.prototype');

Done.

https://codereview.chromium.org/22859012/diff/4001/LayoutTests/fast/events/wh...
LayoutTests/fast/events/wheelevent-basic.html:14:
shouldBe('WheelEvent.DOM_DELTA_PIXEL', '0x00');
On 2013/08/15 14:05:44, arv wrote:
> Can't believe we are adding more numeric constants :'(

Well, this is not a recent spec. It is just recently implemented :)

https://codereview.chromium.org/22859012/diff/4001/LayoutTests/fast/events/wh...
LayoutTests/fast/events/wheelevent-basic.html:34: var expectedDeltaX = deltaX *
tickMultiplier;
On 2013/08/15 14:05:44, arv wrote:
> The main issues historically have been that the deltas have been different
> between browsers. Can we make sure we are fully aligned this time around?

Thanks for bringing my attention to this. I checked and Firefox is using 100 by
default. I am now using 100 for the new API and 120 for the legacy one to
maintain backward compatibility.

https://codereview.chromium.org/22859012/diff/4001/LayoutTests/fast/events/wh...
LayoutTests/fast/events/wheelevent-basic.html:42:
shouldBeUndefined("testEvent.deltaZ"); // Not supported yet.
On 2013/08/15 14:05:44, arv wrote:
> Would it be better to return 0 here for now? What does other browsers return
for
> non z capable scroll wheels?

Done.

https://codereview.chromium.org/22859012/diff/4001/Source/core/dom/WheelEvent...
File Source/core/dom/WheelEvent.idl (right):

https://codereview.chromium.org/22859012/diff/4001/Source/core/dom/WheelEvent...
Source/core/dom/WheelEvent.idl:31: [InitializedByEventConstructor] readonly
attribute long deltaX;
On 2013/08/16 09:57:16, Christophe Dumez wrote:
> These should be "double", not "long". I'll fix this in the next iteration as
> well.

Done.

https://codereview.chromium.org/22859012/diff/4001/Source/core/dom/WheelEvent...
Source/core/dom/WheelEvent.idl:37: [InitializedByEventConstructor,
ImplementedAs=deltaX] readonly attribute long wheelDeltaX;
On 2013/08/15 14:05:44, arv wrote:
> OK. I see, we use the same interface... this should also be deprecated when we
> deprecate onmousewheel.

Right, I use the same interface because the interface name if the same as in the
standard and it is exposed to JavaScript already. We can deprecate (or measure
usage) of the non-standard API in a follow-up patch.

[arv (Not doing code reviews), 2013-08-16 14:19:26]

Peter, didn't you work on our mousewheel impl before? If not please ignore ;-)
What do you think we should use for the values for the deltas?

Christophe, sorry for rat holing on this one.

https://codereview.chromium.org/22859012/diff/4001/LayoutTests/fast/events/wh...
File LayoutTests/fast/events/wheelevent-basic.html (right):

https://codereview.chromium.org/22859012/diff/4001/LayoutTests/fast/events/wh...
LayoutTests/fast/events/wheelevent-basic.html:34: var expectedDeltaX = deltaX *
tickMultiplier;
On 2013/08/16 12:02:50, Christophe Dumez wrote:
> On 2013/08/15 14:05:44, arv wrote:
> > The main issues historically have been that the deltas have been different
> > between browsers. Can we make sure we are fully aligned this time around?
> 
> Thanks for bringing my attention to this. I checked and Firefox is using 100
by
> default. I am now using 100 for the new API and 120 for the legacy one to
> maintain backward compatibility.

My testing in different browsers gave me widely different results:

Firefox, Windows: 3
Firefox, Ubuntu: 3
IE10: 224.42342343534563213143 (don't remember the exact decimals)
Old Opera (using mousewheel): 120
Chrome (using mousewheel): 120

The only sane one here is.... drumroll... IE! The value IE returns is the number
of pixels that would be scrolled.

My proposal is to stick with 120 in this patch. Then file a new bug to match
IE's behavior.

https://codereview.chromium.org/22859012/diff/12001/LayoutTests/fast/events/w...
File LayoutTests/fast/events/wheelevent-mousewheel-interaction.html (right):

https://codereview.chromium.org/22859012/diff/12001/LayoutTests/fast/events/w...
LayoutTests/fast/events/wheelevent-mousewheel-interaction.html:14:
setTimeout(finishJSTest, 0);
Is this because scroll events are async?

[do-not-use, 2013-08-16 15:14:32]

https://codereview.chromium.org/22859012/diff/4001/LayoutTests/fast/events/wh...
File LayoutTests/fast/events/wheelevent-basic.html (right):

https://codereview.chromium.org/22859012/diff/4001/LayoutTests/fast/events/wh...
LayoutTests/fast/events/wheelevent-basic.html:34: var expectedDeltaX = deltaX *
tickMultiplier;
On 2013/08/16 14:19:26, arv wrote:
> On 2013/08/16 12:02:50, Christophe Dumez wrote:
> > On 2013/08/15 14:05:44, arv wrote:
> > > The main issues historically have been that the deltas have been different
> > > between browsers. Can we make sure we are fully aligned this time around?
> > 
> > Thanks for bringing my attention to this. I checked and Firefox is using 100
> by
> > default. I am now using 100 for the new API and 120 for the legacy one to
> > maintain backward compatibility.
> 
> My testing in different browsers gave me widely different results:
> 
> Firefox, Windows: 3
> Firefox, Ubuntu: 3
> IE10: 224.42342343534563213143 (don't remember the exact decimals)
> Old Opera (using mousewheel): 120
> Chrome (using mousewheel): 120
> 
> The only sane one here is.... drumroll... IE! The value IE returns is the
number
> of pixels that would be scrolled.
> 
> My proposal is to stick with 120 in this patch. Then file a new bug to match
> IE's behavior.

Firefox gave you 3? But likely the unit was in number of lines, not in pixels
(see deltaMode attribute), right?

[do-not-use, 2013-08-16 15:24:10]

https://codereview.chromium.org/22859012/diff/12001/LayoutTests/fast/events/w...
File LayoutTests/fast/events/wheelevent-mousewheel-interaction.html (right):

https://codereview.chromium.org/22859012/diff/12001/LayoutTests/fast/events/w...
LayoutTests/fast/events/wheelevent-mousewheel-interaction.html:14:
setTimeout(finishJSTest, 0);
On 2013/08/16 14:19:27, arv wrote:
> Is this because scroll events are async?

I don't think this is needed actually. I'll check.

[arv (Not doing code reviews), 2013-08-16 16:08:16]

On 2013/08/16 15:14:32, Christophe Dumez wrote:
>
https://codereview.chromium.org/22859012/diff/4001/LayoutTests/fast/events/wh...
> File LayoutTests/fast/events/wheelevent-basic.html (right):
> 
>
https://codereview.chromium.org/22859012/diff/4001/LayoutTests/fast/events/wh...
> LayoutTests/fast/events/wheelevent-basic.html:34: var expectedDeltaX = deltaX
*
> tickMultiplier;
> On 2013/08/16 14:19:26, arv wrote:
> > On 2013/08/16 12:02:50, Christophe Dumez wrote:
> > > On 2013/08/15 14:05:44, arv wrote:
> > > > The main issues historically have been that the deltas have been
different
> > > > between browsers. Can we make sure we are fully aligned this time
around?
> > > 
> > > Thanks for bringing my attention to this. I checked and Firefox is using
100
> > by
> > > default. I am now using 100 for the new API and 120 for the legacy one to
> > > maintain backward compatibility.
> > 
> > My testing in different browsers gave me widely different results:
> > 
> > Firefox, Windows: 3
> > Firefox, Ubuntu: 3
> > IE10: 224.42342343534563213143 (don't remember the exact decimals)
> > Old Opera (using mousewheel): 120
> > Chrome (using mousewheel): 120
> > 
> > The only sane one here is.... drumroll... IE! The value IE returns is the
> number
> > of pixels that would be scrolled.
> > 
> > My proposal is to stick with 120 in this patch. Then file a new bug to match
> > IE's behavior.
> 
> Firefox gave you 3? But likely the unit was in number of lines, not in pixels
> (see deltaMode attribute), right?

You are correct.

I think the important part is that given an element that is currently scrolled
all the way to the top (scrollTop == 0) and we scroll down using the mouse
wheel, the scrollTop should now match -e.deltaY (and we should use
DOM_DELTA_PIXEL).

[do-not-use, 2013-08-16 17:16:32]

On 2013/08/16 14:19:26, arv wrote:
> Peter, didn't you work on our mousewheel impl before? If not please ignore ;-)
> What do you think we should use for the values for the deltas?

Sorry, who is Peter? I don't recognize him from the CC list.

[do-not-use, 2013-08-16 17:32:33]

https://codereview.chromium.org/22859012/diff/4001/LayoutTests/fast/events/wh...
File LayoutTests/fast/events/wheelevent-basic.html (right):

https://codereview.chromium.org/22859012/diff/4001/LayoutTests/fast/events/wh...
LayoutTests/fast/events/wheelevent-basic.html:34: var expectedDeltaX = deltaX *
tickMultiplier;
On 2013/08/16 15:14:32, Christophe Dumez wrote:
> On 2013/08/16 14:19:26, arv wrote:
> > On 2013/08/16 12:02:50, Christophe Dumez wrote:
> > > On 2013/08/15 14:05:44, arv wrote:
> > > > The main issues historically have been that the deltas have been
different
> > > > between browsers. Can we make sure we are fully aligned this time
around?
> > > 
> > > Thanks for bringing my attention to this. I checked and Firefox is using
100
> > by
> > > default. I am now using 100 for the new API and 120 for the legacy one to
> > > maintain backward compatibility.
> > 
> > My testing in different browsers gave me widely different results:
> > 
> > Firefox, Windows: 3
> > Firefox, Ubuntu: 3
> > IE10: 224.42342343534563213143 (don't remember the exact decimals)
> > Old Opera (using mousewheel): 120
> > Chrome (using mousewheel): 120
> > 
> > The only sane one here is.... drumroll... IE! The value IE returns is the
> number
> > of pixels that would be scrolled.
> > 
> > My proposal is to stick with 120 in this patch. Then file a new bug to match
> > IE's behavior.
> 
> Firefox gave you 3? But likely the unit was in number of lines, not in pixels
> (see deltaMode attribute), right?
> 

I confirm that Firefox uses 100 as multiplier for x, y and z by default. the
multipliers for those 3 axis are settings that the user can customize via
about:config. This is the reason why I used 100 in the latest patch, however,
allowing the user to customize it like Firefox does may not be a bad idea.

[arv (Not doing code reviews), 2013-08-16 17:40:01]

On 2013/08/16 17:16:32, Christophe Dumez wrote:
> On 2013/08/16 14:19:26, arv wrote:
> > Peter, didn't you work on our mousewheel impl before? If not please ignore
;-)
> > What do you think we should use for the values for the deltas?
> 
> Sorry, who is Peter? I don't recognize him from the CC list.

I forgot to re-add pkasting after going back to modify a previous comment. At
this point I think we know what the correct behavior is so I'm not going to
bother him any more.

[arv (Not doing code reviews), 2013-08-16 17:52:31]

On 2013/08/16 17:32:33, Christophe Dumez wrote:
>
https://codereview.chromium.org/22859012/diff/4001/LayoutTests/fast/events/wh...
> File LayoutTests/fast/events/wheelevent-basic.html (right):
> 
>
https://codereview.chromium.org/22859012/diff/4001/LayoutTests/fast/events/wh...
> LayoutTests/fast/events/wheelevent-basic.html:34: var expectedDeltaX = deltaX
*
> tickMultiplier;
> On 2013/08/16 15:14:32, Christophe Dumez wrote:
> > On 2013/08/16 14:19:26, arv wrote:
> > > On 2013/08/16 12:02:50, Christophe Dumez wrote:
> > > > On 2013/08/15 14:05:44, arv wrote:
> > > > > The main issues historically have been that the deltas have been
> different
> > > > > between browsers. Can we make sure we are fully aligned this time
> around?
> > > > 
> > > > Thanks for bringing my attention to this. I checked and Firefox is using
> 100
> > > by
> > > > default. I am now using 100 for the new API and 120 for the legacy one
to
> > > > maintain backward compatibility.
> > > 
> > > My testing in different browsers gave me widely different results:
> > > 
> > > Firefox, Windows: 3
> > > Firefox, Ubuntu: 3
> > > IE10: 224.42342343534563213143 (don't remember the exact decimals)
> > > Old Opera (using mousewheel): 120
> > > Chrome (using mousewheel): 120
> > > 
> > > The only sane one here is.... drumroll... IE! The value IE returns is the
> > number
> > > of pixels that would be scrolled.
> > > 
> > > My proposal is to stick with 120 in this patch. Then file a new bug to
match
> > > IE's behavior.
> > 
> > Firefox gave you 3? But likely the unit was in number of lines, not in
pixels
> > (see deltaMode attribute), right?
> > 
> 
> I confirm that Firefox uses 100 as multiplier for x, y and z by default. the
> multipliers for those 3 axis are settings that the user can customize via
> about:config. This is the reason why I used 100 in the latest patch, however,
> allowing the user to customize it like Firefox does may not be a bad idea.

100 actually means 1. https://wiki.mozilla.org/Gecko:Mouse_Wheel_Scrolling. My
mousewheel.default.delta_multiplier_y is set to 100 as well but it still returns
3. And the amount the page is scrolled is 57px. According to their wiki it is
platform dependent and OS dependent. The more I read about this the more
convinced I get that we should always use the actual pixels we would scroll.

[do-not-use, 2013-08-16 18:29:42]

Ok, I reverted my changes to the TickMultiplier from this CL. We can improve
this in a follow-up patch.

[arv (Not doing code reviews), 2013-08-16 18:37:45]

LGTM

Sorry about all the churn.

https://codereview.chromium.org/22859012/diff/57001/Source/core/dom/EventTarg...
File Source/core/dom/EventTarget.cpp (right):

https://codereview.chromium.org/22859012/diff/57001/Source/core/dom/EventTarg...
Source/core/dom/EventTarget.cpp:179: static AtomicString prefixedType(const
Event* event)
This might be better named as legacyType now?

https://codereview.chromium.org/22859012/diff/57001/Source/core/dom/EventTarg...
Source/core/dom/EventTarget.cpp:200: AtomicString prefixedTypeName =
prefixedType(event);
AtomicString legacyTypeName = legacyType(event);

here too then.

[do-not-use, 2013-08-16 18:46:14]

On 2013/08/16 18:37:45, arv wrote:
> LGTM
> 
> Sorry about all the churn.

No worries, it is important to get things right.

> 
>
https://codereview.chromium.org/22859012/diff/57001/Source/core/dom/EventTarg...
> File Source/core/dom/EventTarget.cpp (right):
> 
>
https://codereview.chromium.org/22859012/diff/57001/Source/core/dom/EventTarg...
> Source/core/dom/EventTarget.cpp:179: static AtomicString prefixedType(const
> Event* event)
> This might be better named as legacyType now?
> 
>
https://codereview.chromium.org/22859012/diff/57001/Source/core/dom/EventTarg...
> Source/core/dom/EventTarget.cpp:200: AtomicString prefixedTypeName =
> prefixedType(event);
> AtomicString legacyTypeName = legacyType(event);
> 
> here too then.

I agree. This is fixed now.

[do-not-use, 2013-08-19 19:52:42]

This received enough support on the mailing list. LGTMs from abarth, jochen and
dglazkov.

Could an API owner please take a look at the patch?

[jochen (gone - plz use gerrit), 2013-08-20 08:15:37]

lgtm

[commit-bot: I haz the power, 2013-08-20 09:08:20]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/ch.dumez@sisa.samsung.com/22859012/13027

[commit-bot: I haz the power, 2013-08-20 19:06:50]

Change committed as 156404