111647 - onmousewheel event

Status: RESOLVED WONTFIX

(Core :: DOM: Events, enhancement, P3)

Description

[jonathan chetwynd]

2 other URIs are:
http://www.webreference.com/js/tips/010717.html
http://msdn.microsoft.com/workshop/author/dhtml/reference/events/onmousewheel.html
All 3 require IE6.

the onmousewheel event can be captured and used in javascript to enhance
interactivity.

It is important that users should be able to tab to images and then mousewheel.
The first URI is an example that is reported to work in windowsXP, in windows'98
one can only mouse to the image and then mousewheel.

Comment 1

[jonathan chetwynd]

forgot to add uri: http://www.peepo.com/2k1/mousewheel/index.html of project I am working on ,a toolbar, currently under development, and working (without tab) in IE6

Comment 2

[Pham]

http://bugzilla.mozilla.org/show_bug.cgi?id=179125#c3

joki is no longer here

Comment 3

[jonathan chetwynd]

Mozilla now works the scroll bar from the wheel, but javascript seems not to be interacting with 
the wheel....

examples are needed that work with mozilla

the ones listed above dont work for me in mozilla

after 2 years is this like watching concrete set, or perhaps paint dry?

does anyone have an opinion on this Ian?

thanks

Comment 4

[Vedran Miletic]

retargeting

Comment 5

[David Baron :dbaron:]

We already have a "DOMMouseScroll" event.  Does that just need to be hooked up
to the onmousewheel attribute?

Comment 6

[David Baron :dbaron:]

See bug 108757 for the DOMMouseScroll event patch.

Comment 7

[Tomer Chachamu]

The new design at http://www.ld4all.com is broken because of this. Hoping this
can be made soon.

Comment 8

[Gérard Talbot]

Mozilla supports DOMMouseScroll event which is the equivalent of MSIE's
mousewheel event.

I think the name of events should have been thought more carefully;
mousewheelroll and mousewheelclick are much more significant descriptions of
possible events. DOMMouseScroll or mousewheel are not best descriptive.

I visited http://www.ld4all.com (nice looking site btw) and the Microsoft Script
Debugger complained twice about unterminated string litteral in document.write()
calls which were not related to the mousewheel event handler function. In any
cases, that site could work as intended and accordingly with/for Mozilla
browsers when rolling the mousewheel.

Comment 9

[Tomer Chachamu]

How, then? How can DOMMouseScroll be made to do the same as onMouseWheel?

A contributor has been fixing the JS errors but it's yet to go live.

Comment 10

[Hixie (not reading bugmail)]

This bug needs:
 * a single clear testcase, attached to the bug using the attachment feature
 * clear steps to reproduce using that testcase
 * an explanation of what happens that is considered the bug
 * an explanation of what exactly should happen instead for the bug to be fixed

At the moment it has none of these. I don't really understand what is being
requested at this point.

Comment 11

[jonathan chetwynd]

Attachment: test for mouswheel event

Comment 12

[jonathan chetwynd]

Attachment: test for mousewheel event

Comment 13

[jonathan chetwynd]

This bug is over 3 years old, yet mouse commonly have a wheel.

The attachment demonstrates this:
Mouseover or tab to the graphic, then use the mousewheel, which should raise an
alert dialogue. It doesn't.

Mozilla doesn't currently appear to support onmousewheel or event.wheelDelta*.

----

*using scripting it should be possible to provide a variety of interactions.

for instance zoom in and out on a picture:
http://www.peepo.com/2k1/mousewheel/tabindex.html

scroll rapidly through a range of graphics:
http://www.peepo.com/2k1/mousewheel/index.html

scroll through text:
http://www.peepo.com/2k1/mousewheel/index.html

Comment 14

[Tomer Chachamu]

Can this be reassigned to somebody who isn't gone?

I wouldn't expect this to be hard to implement...

Comment 15

[Gérard Talbot]

We have so far established that Gecko supports the event DOMMouseScroll which
is, for practical reasons, the MSIE 6 equivalent of mousewheel event. The only
issue which was remaining was the equivalent of MSIE 6's event.wheelDelta for
Mozilla-based browsers. After a bit of investigation, I figured out that
evt.detail property was storing the value necessary to determine the direction
of the mouse wheel roll event with the value coming from the constants
SCROLL_PAGE_UP   = -32768
SCROLL_PAGE_DOWN = 32768

So, with all this, we can place the mouse cursor over an image, then roll
forward (or backward) the mouse wheel and then programmatically and accordingly
increase (or decrease) the image dimensions. Same thing with text size or
anything (CSS property value) which can be increased or decreased.

http://www.gtalbot.org/Bugzilla/Bug111647.html

will work in MSIE 6, Mozilla 1.8b2, NS 7.0, NS 7.1, NS 7.2, Firefox 1.0.2, etc..
The thing is that probably every single release of Mozilla since 2001-11-14 most
likely was able to do what the reporter was asking for.

Please, folks: Always write an useful summary, a clear description (or an
explanation of what exactly should happen instead for the bug to be fixed),
expected results, actual results and a reduced testcase. 

> This bug is over 3 years old, yet mouse commonly have a wheel.
Bug 20618: Mousewheel doesn't work with some driver/Win32 OS combinations
(scroll, scrolling) is the top most frequently reported bug. And even today, I
would not say that 66% of all Windows-os users have a mouse with a rolling wheel.

I will resolve this bug as WORKSFORME unless I hear excellent reasons not to.

Comment 16

[Fabricio Campos Zuardi]

Just tested the url http://www.gtalbot.org/Bugzilla/Bug111647.html on a Firefox
1.0.2 "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317
Firefox/1.0 " and the cat picture didn't resize with mousewheel, on IE6 it works
:((.

Comment 17

[Gérard Talbot]

I just tested the page with FF 1.0.2 on XP Pro SP2 (same configuration as yours)
and the cat picture resizes accordingly. Make sure you have javascript enabled.
I have other pages where mousewheel roll event (and its direction - forward or
backward) can be detected and they work in FF 1.0.2:

http://www.gtalbot.org/BrowserBugsSection/MozillaBugs/Bug189308_ScrollEvent.html
http://www.gtalbot.org/HTMLJavascriptCSS/DUWindowsNS6.html (pushpin down the
Mouse event coordinates layer and then roll the wheel: the current event type
should indicate the direction)

In your about:config, do you have user defined values for mousewheel.with*.*
properties; e.g. mousewheel.withnokey.action? Do you use some extensions which
may interfere with mousewheel? Do you see/get error messages in the javascript
console when you try to resize the cat image? Do you see the event constants,
properties and methods of the event object generated when you check the checkbox?

Comment 18

[Gérard Talbot]

After a quick chat with I. Hickson, I am resolving this bug as WORKSFORME  

Comment 19

[Tim Powell]

I'd suggest reopening this. Why was it closed as worksforme despite comment 16
clearly saying it doesn't work? I have the same problem with basically the same
configuration as in comment 16 (the key difference being Win XP not SP2). My
mousewheel works fine for scrolling Firefox windows and textareas, but the image
in the testcase at http://www.gtalbot.org/Bugzilla/Bug111647.html does not
resize. It works just fine with IE6 on the same machine.

Using the following testcase
http://www.gtalbot.org/BrowserBugsSection/MozillaBugs/Bug189308_ScrollEvent.html
I can scroll the window with the mousewheel and it counts the mousewheel roll
events.

For what it's worth, I'm using the IBM ScrollPoint mouse with the standard
Microsoft mouse drivers and everything that should scroll in Mozilla seems to do
so. Bug 20618 seems to be an all or nothing kind of problem, not a specific case
of not scrolling as mentioned in this bug.

I thought the point of this bug was to provide support for the Microsoft-created
onmousewheel event as mentioned in the first webreference.com URL in comment 0.
That seems a reasonable testcase. Hover the mouse over the image and spin the
mousewheel. The image should move up or down. If it does, this bug is fixed.

Comment 20

[Fabricio Campos Zuardi]

Attachment: http://www.gtalbot.org/Bugzilla/Bug111647.html after mousewheel scroll

Comment 21

[Fabricio Campos Zuardi]

Attachment: A screenshot of my about config containing the mousewheel preferences

Comment 22

[Fabricio Campos Zuardi]

Attachment: http://www.gtalbot.org/BrowserBugsSection/MozillaBugs/Bug189308_ScrollEvent.html after mousewheel

Comment 23

[Fabricio Campos Zuardi]

Attachment: http://www.gtalbot.org/HTMLJavascriptCSS/DUWindowsNS6.html after some mousewheel

Comment 24

[Gérard Talbot]

> I'd suggest reopening this. Why was it closed as worksforme despite comment 16
> clearly saying it doesn't work?

There are a number of issues and questions which the people who wanted this bug
to be fixed have not yet explicitly and clearly answered. A few of them were
asked in comment #10. Tomer, you asked "How can DOMMouseScroll be made to do the
same as onMouseWheel?" and I provided a testcase which worked for me (I am using
a Logitech Optical Mouse - 2nd generation - on a USB port with driver version
9.79; Human Interface Device (HID) compliant WheelMouse) and it worked for
others as well.

> I'm using the IBM ScrollPoint mouse with the standard
> Microsoft mouse drivers 

Are you using the latest mouse driver for your mouse (version, model, etc)?
http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-54227

> Bug 20618 seems to be an all or nothing kind of problem, not a specific case
> of not scrolling as mentioned in this bug.

I was merely pointing out that the mousewheel technology (drivers,
interoperability across softwares, platforms, os) does not universally,
completely and perfectly work for everyone. Some mouse with mousewheel were sold
in 1998 (1st generation). A mousewheel on a mouse could be common nowadays to a
mouse but unfortunately this is not sufficient.
Even if (MSIE 6) mousewheel event (and wheelDelta property) was mapped to
DOMMouseScroll event type, it might still not make Mozilla-based browsers render
accordingly the 2 urls mentioned in the Description.

> I thought the point of this bug was to provide support for the 
> Microsoft-created onmousewheel event as mentioned in the first
> webreference.com URL in comment 0.

I thought it was sufficient for this bug to be resolved if a way to detect
direction of mousewheel rolling in Mozilla-based browsers was found. If I was
wrong, then please resummarize accordingly and explicit steps to reproduce,
expected results, etc..

Fabricio, are you using the latest driver for your mouse? 
The best place to update driver software is to start with windows update;
sometimes/often, you can get more recent updates of driver software at the
manufacturer's (of the hardware) website.

Fabricio, your attachment 179920 [details] show these info:
BUBBLING_PHASE = 3
SCROLL_PAGE_DOWN = 32768
SCROLL_PAGE_UP = -32768
detail = 3
eventPhase = 0
The code of the catimage page cancels the event propagation.

Do you use some extensions which may interfere with mousewheel? Do you see/get
error messages in the javascript console when you try to resize the cat image?

Comment 25

[Gérard Talbot]

> The code of the catimage page cancels the event propagation.
Oops.. that's not true. The code doesn't cancel the event propagation but rather
just the default action.

Comment 26

[:Gavin Sharp [email: [e-mail]]]

*** Bug 291038 has been marked as a duplicate of this bug. ***

Comment 27

[Peter van der Woude [:Peter6]]

(In reply to comment #25)
> > The code of the catimage page cancels the event propagation.
> Oops.. that's not true. The code doesn't cancel the event propagation but rather
> just the default action.
I notice you changed status a few times, however , this doesn't work on either
trunk or branch

Comment 28

[Mardeg]

(In reply to comment #27)
> ... this doesn't work on either trunk or branch

I used some alerts in the example page and noticed for some reason the roll 
values aren't always -32768 or +32768. In fact I got -1 and 1. Seems simpler to 
just assign either the IE or gecko event value to a variable for greater 
than/less than comparison to 0, eliminating the need for duplicate code for 
actions. Only thing to remember is the negative/positive values reflect 
opposite forward/backward actions for the two browsers, so scripters need to 
remember when assigning to a variable, reverse either the IE or the Gecko 
value: variable = (typeof(event.detail) == number)?-
(event.detail):event.wheelDelta   or vice versa

Comment 29

[Gérard Talbot]

> I used some alerts in the example page and noticed for some reason the roll 
> values aren't always -32768 or +32768. In fact I got -1 and 1.

That's because you most likely have your mousewheel default to 1 line of
scrolling per notch of rolling the mousewheel. If you had one screen at a time,
it would have defaulted to ±32768.

Fabricio Campos Zuardi had its evt.detail value to 3 in attachment 179920 [details] when
rolling backward: so his setting must have been 3 lines per notch. Not one
screen at a time per notch.

Values under 25 lines of scrolling in XP are reliable and will be reported
accordingly in the evt.detail property value. At 25 or over, the number of lines
are greater than 1 screen and the value gets modified in the evt.detail property
value.

I ask people to give this page another try:

http://www.gtalbot.org/BugzillaSection/Bug111647.html

If the page works as expected, as intended, then please say so along with os
name/version, Seamonkey or DeerPark browser build, mousewheel setting in the os
(1), driver version and driver version date.

The XP users, like Fabricio Campos Zuardi, should have no problem with the page
now as long as they are using a recent version of mousewheel.

If the page does not work as expected, as intended, then please say so along
with os name/version, Seamonkey or DeerPark browser version and build
(preferably recent), mousewheel setting in the os, driver version and driver
version date. Saying "it does not work" is not particularly helpful.
--
(1) In XP: Start/Settings/Control Panel/Mouse/Wheel tab/Roll the wheel one notch
to scroll: and then the specific setting

Comment 30

[jonathan chetwynd]

os X 10.4 Panther
deerpark 1.0+ alpha
logitech cordless trackman wheel

wfm: http://www.gtalbot.org/BugzillaSection/Bug111647.html

but http://www.webreference.com/js/tips/010717.html does not.

is "onmousewheel" to be supported? 

Comment 31

[Anne (:annevk)]

Logically the handler would be called "onDOMMouseScroll" as the event we support
is "DOMMouseScroll", which is not standard...

Comment 32

[Garrett Smith]

Attachment: Demo: DOMMouseWheel event listener captures mousewheel events

The original complaint: 

> It is important that users should be able to tab to images and then
mousewheel.
> The first URI is an example that is reported to work in windowsXP, in
windows'98
> one can only mouse to the image and then mousewheel.

The issue has been resolved by this testcase.

Comment 33

[Tim Powell]

Yes, there are ways to work around the lack of support for the onmousewheel
event. DOMMouseScroll added in bug 108757 captures the scroll events. 

The onmousewheel event still does not work. See comment 0 for example URIs and
testcases. While it is nice that there are ways to capture the wheel scroll
events in Mozilla, this is a compatibility issue with existing pages that
utilize the Microsoft created onmousewheel event. I don't see the benefit of
have yet another non-standard event.

If onmousewheel is not going to be supported, resolve this as invalid, otherwise
let's get the DOMMouseScroll event hooked up to onmousewheel like David Baron
suggested.

Comment 34

[jonathan chetwynd]

http://www.gtalbot.org/BugzillaSection/Bug111647.html
worksforme on os x

resolving as wontfix as after more than six years it appears to be the chosen path regarding the other open issues discussed above

Comment 38

[Sven Neuhaus]

Regarding comment 32: The title of this bug is "onmousewheel event".

Regarding comment 34: http://www.gtalbot.org/BugzillaSection/Bug111647.html is not a proper test case for this because it uses "DOMMouseScroll", not "onmousewheel".

I have created a testcase at
http://members.ping.de/~sven/mozbug/onmousewheel.html
that uses onmousewheel. It fails on Firefox 10.0.2.

As you can see at http://www.javascriptkit.com/javatutors/onmousewheel.shtml
Firefox is the *only* browser that doesn't support "onmousewheel" and the wheelDelta property of the resulting event.
Apparently, prior to Firefox 3.0 it actually was supported!

Is there a real reason why this de-facto-standard is not being followed? It's not too late. It is still annoying developers who have to code around it. Please fix it.

Comment 39

[Boris Zbarsky [:bzbarsky]]

There's a spec for this at http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-wheelevents

Why does that not match what browsers actually implement?  Olli?

Comment 40

[Olli Pettay [:smaug][[e-mail]]]

All the browsers which implement mousewheel event implement it in very different ways.
mousewheel can't also support all the needed features without breaking backwards compatibility.
We should implement wheel event. It is already supported at least in IE9, IIRC.

Comment 41

[Gérard Talbot]

(In reply to Sven Neuhaus from comment #38)
> Regarding comment 34: http://www.gtalbot.org/BugzillaSection/Bug111647.html
> is not a proper test case for this because it uses "DOMMouseScroll", not
> "onmousewheel".

http://www.gtalbot.org/BugzillaSection/Bug111647.html
was and is using a forking feature detection at lines 121 and 124 and so it was coded for onmousewheel (line 51).

> I have created a testcase at
> http://members.ping.de/~sven/mozbug/onmousewheel.html
> that uses onmousewheel. It fails on Firefox 10.0.2.

Your test better targeted this bug report (mousewheel event) than mine: agreed. It must be noted that mousewheel event only was standardized in 2006. And today, event.wheelDelta is not part of the DOM3 Events spec. mousewheel event was dropped in the DOM3 Events starting with the 20100907 WD and was replaced with/in favor of wheel event.

http://www.w3.org/TR/DOM-Level-3-Events/#events-wheelevents
now gives

  const unsigned long              DOM_DELTA_PIXEL = 0x00;
  const unsigned long              DOM_DELTA_LINE  = 0x01;
  const unsigned long              DOM_DELTA_PAGE  = 0x02;

  readonly attribute double         deltaX;
  readonly attribute double         deltaY;
  readonly attribute double         deltaZ;
  readonly attribute unsigned long deltaMode;


(In reply to Olli Pettay [:smaug] from comment #40)
> All the browsers which implement mousewheel event implement it in very
> different ways.
> mousewheel can't also support all the needed features without breaking
> backwards compatibility.
> We should implement wheel event.

3 Tests at IE test center on wheel event (and NOT mousewheel event):

http://samples.msdn.microsoft.com/ietestcenter/domevents/WheelEvent.hasFeature.html

http://samples.msdn.microsoft.com/ietestcenter/domevents/WheelEvent.ctrlKey.zoom.html

http://samples.msdn.microsoft.com/ietestcenter/domevents/WheelEvent.deltaMode.html

and Firefox 19.0.2 passes all 3.

Comment 42

[Gérard Talbot]

Interactive DOM 3 Events wheel (rolling) event properties webpage
http://www.gtalbot.org/BugzillaSection/BugXXXXXX-wheel-event.html
(please do not bookmark this page as I may later filename-rename it.)

I have added a very long word so that mousewheel.horizscroll.(modifier key).(type) values could be tested on platforms that support mousewheel.horizscroll.(modifier key).(type): see
http://kb.mozillazine.org/About:config_entries#Mousewheel.
for more details.

mousewheel.with_[alt|control|meta|shift|win] can be checked too.

Just click the checkbox "Append below all event constants, properties and methods of the event object" to see altKey, ctrlKey, metaKey, shiftKey values.

DOM 3 events, section 5.2.4 Wheel Event Types
http://www.w3.org/TR/DOM-Level-3-Events/#events-wheelevents

Firefox 19.0.2 passes this meta-test.
Chrome 25.0.1364.172 and Opera 12.14 do not report any value.

Can someone check how well IE9 and IE10 handle that meta-test page?

Gérard

Comment 43

[Gérard Talbot]

> mousewheel.horizscroll.(modifier key).(type): see
> http://kb.mozillazine.org/About:config_entries#Mousewheel.
> for more details.

see

http://kb.mozillazine.org/About:config_entries#Mousewheel%2E
(percent encoding of full stop required)

Comment 44

[Gérard Talbot]

> Interactive DOM 3 Events wheel (rolling) event properties webpage
> (please do not bookmark this page as I may later filename-rename it.)

The page
Interactive DOM 3 Events wheel (rolling) event properties webpage
is now at
http://www.gtalbot.org/DHTMLSection/DOM3-events-wheel-event.html
and you can bookmark it!

Comment 45

[Sven Neuhaus]

The "onmousewheel" event (under that name, not "DOMMouseScroll") is still unsupported as of Firefox 22.

The event "onmousewheel" is part of the HTML5 Web Application API, see
http://dev.w3.org/html5/spec-LC/webappapis.html

Comment 46

[Gérard Talbot]

(In reply to Sven Neuhaus from comment #45)
> The "onmousewheel" event (under that name, not "DOMMouseScroll") is still
> unsupported as of Firefox 22.
> 
> The event "onmousewheel" is part of the HTML5 Web Application API, see
> http://dev.w3.org/html5/spec-LC/webappapis.html

Sven, 

This bug report was/is about DOM 3 events. As far as DOM 3 event wheel is involved, this bug has been fixed: event.DOM_DELTA_PIXEL , event.DOM_DELTA_LINE , event.DOM_DELTA_PAGE , event.deltaX , event.deltaY and event.deltaZ are supported.

I have modified the Summary line of this bug report.

Now, you need to create a new separate bug report for HTML5 and link it to
6.1.6.2 Event handlers on elements, Document objects, and Window objects
http://dev.w3.org/html5/spec-LC/webappapis.html#event-handlers-on-elements-document-objects-and-window-objects

Comment 47

[Gérard Talbot]

DOM 3 Events spec is still in working draft but since 2 implementations already support wheel event, it's not likely that it will change in the future. 

As for HTML5, I do not know if the "onmousewheel" event handler name is going to remain as is.

Comment 48

[Sven Neuhaus]

Dear Gérard,

why do you write that this bug was about DOM3 events? It clearly was about the onmousewheel event when it was opened in 2001 by jonathan. In 2004 you were the one (in comment 8) who started talking about the DOMMouseScroll event.

jonathan also provided a simple testcase (attachment 168205 [details]) and it shows exactly what the problem is (and it is still a problem with today's Firefox).

The fact is the official, final HTML 5 standard calls it "onmousewheel" and all other browsers support it using that name. That is the thing about standards, they don't change after they have been defined and finalzed! And "onmousewheel" is even in the HTML 5.1 draft standard, so it appears that the event will keep it's name in the forseeable future.

It's great that there is *some* way to access the mouse wheel in Firefox using the DOM3 WheelEvent. However, that's not what this bug is about. It's about using the onmousewheel event in all browsers, including Firefox. Less polyfills, less inconsistencies, less work for web developers, less broken sites for users.

Comment 49

[Olli Pettay [:smaug][[e-mail]]]

HTML spec doesn't define mousewheel event in any way. There is just onmousewheel property in GlobalEventHandlers.

Comment 50

[Boris Zbarsky [:bzbarsky]]

> The fact is the official, final HTML 5 standard calls it "onmousewheel" 

Fwiw, there is nothing even close to a "final HTML5 standard"....

Comment 51

[Masatoshi Kimura [:emk]]

D3E defines "wheel" event type but not "mouzewheel" event type.
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html

Comment 52

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

onmousewheel should be dropped from HTML5 spec.
See https://www.w3.org/Bugs/Public/show_bug.cgi?id=18542

Additionally, we cannot implement mousewheel event because its delta value is different between all browsers which implement.
See https://developer.mozilla.org/en-US/docs/DOM/DOM_event_reference/mousewheel#wheelDelta.2C_wheelDeltaX_and_wheelDeltaY_value

* IE, Chrome on Windows, Chrome on Linux Chrome on Mac with non-continuous scrollable device set *physical* wheel turned amount to the delta value.

* Chrome on Mac with continuous scrollable device and Safari set logical scroll amount in pixels to the delta value.

* Opera on all platforms sets scroll amount in lines to detail and detail value * 40 to the delta value.

So, we have no motivation to implement legacy mousewheel event since we've already implemented better event, D3E wheel event and onwheel event for it.

Comment 53

[Gérard Talbot]

> why do you write that this bug was about DOM3 events? It clearly was about
> the onmousewheel event when it was opened in 2001 by jonathan. 

The spec changed and I explained in detail what, how and why in comment #41.

> In 2004 you
> were the one (in comment 8) who started talking about the DOMMouseScroll
> event.

That's because there were no standard at that time, in 2004; so, "DOMMouseScroll" and "mousewheel" or "fooscroll" or "whatever" were possible. Gecko engine was using DOMMouseScroll as the event type.
If no standard, then no consistency.

> jonathan also provided a simple testcase (attachment 168205 [details]) and
> it shows exactly what the problem is (and it is still a problem with today's
> Firefox).
> 
> The fact is the official, final HTML 5 standard calls it "onmousewheel" 

As I said, it's an event handler in HTML5. Not part of DOM 3 events spec. 2 different and distinct matters. Which should go in 2 distinct, separate bug reports.

> and
> all other browsers support it using that name. That is the thing about
> standards, they don't change after they have been defined and finalzed! 

The "standards" changed. A draft version is not like a Proposed Recommendation. 
It's wheel now, not mousewheel. And you can expect browsers to comply from now on. By the way, I have asked how IE9 and IE10 handle 

http://www.gtalbot.org/DHTMLSection/DOM3-events-wheel-event.html

Anyone can tell me how IE11 preview handle such page ?

> And
> "onmousewheel" is even in the HTML 5.1 draft standard, so it appears that
> the event will keep it's name in the forseeable future.

Your opinion. 
My opinion is that it is better to have consistency in naming things. With "wheel" here (DOM3 events) and "onmousewheel" over there (HTML5): my crystal ball suggests people will eventually complain about inconsistent and confusing naming schemes.

(That's exactly also what 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18542
is about)

> It's great that there is *some* way to access the mouse wheel in Firefox
> using the DOM3 WheelEvent. However, that's not what this bug is about.

All I did was claim that this DOM3 Events bug report was resolved. If you want onmousewheel event handler to be supported, as part of HTML5, then please create another separate bug report for that.

Gérard

Comment 54

[Sven Neuhaus]

So this bug is 17 years old?
It looks as if all browsers these days support the DOM Level 3 "wheel" event.
Therefore the solution should be to switch to onwheel with the deltaY and deltaMode event attributes.

Closing as WONTFIX (by passage of time)