2 other URIs are:
All 3 require IE6.
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.
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
joki is no longer here
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?
We already have a "DOMMouseScroll" event. Does that just need to be hooked up
to the onmousewheel attribute?
See bug 108757 for the DOMMouseScroll event patch.
The new design at http://www.ld4all.com is broken because of this. Hoping this
can be made soon.
Mozilla supports DOMMouseScroll event which is the equivalent of MSIE's
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.
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.
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.
Created attachment 168204 [details]
test for mouswheel event
Created attachment 168205 [details]
test for mousewheel event
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:
scroll rapidly through a range of graphics:
scroll through text:
Can this be reassigned to somebody who isn't gone?
I wouldn't expect this to be hard to implement...
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.
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.
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
I just tested the page with FF 1.0.2 on XP Pro SP2 (same configuration as yours)
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:
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
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?
After a quick chat with I. Hickson, I am resolving this bug as WORKSFORME
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
I can scroll the window with the mousewheel and it counts the mousewheel roll
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.
Created attachment 179920 [details]
http://www.gtalbot.org/Bugzilla/Bug111647.html after mousewheel scroll
Created attachment 179921 [details]
A screenshot of my about config containing the mousewheel preferences
Created attachment 179922 [details]
http://www.gtalbot.org/BrowserBugsSection/MozillaBugs/Bug189308_ScrollEvent.html after mousewheel
Created attachment 179924 [details]
> 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)?
> 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
> 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.
*** Bug 291038 has been marked as a duplicate of this bug. ***
(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
(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
> 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
I ask people to give this page another try:
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
os X 10.4 Panther
deerpark 1.0+ alpha
logitech cordless trackman wheel
but http://www.webreference.com/js/tips/010717.html does not.
is "onmousewheel" to be supported?
Logically the handler would be called "onDOMMouseScroll" as the event we support
is "DOMMouseScroll", which is not standard...
Created attachment 192575 [details]
Demo: DOMMouseWheel event listener captures mousewheel events
The original complaint:
> It is important that users should be able to tab to images and then
> The first URI is an example that is reported to work in windowsXP, in
> one can only mouse to the image and then mousewheel.
The issue has been resolved by this testcase.
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
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
*** Bug 464243 has been marked as a duplicate of this bug. ***
*** Bug 537627 has been marked as a duplicate of this bug. ***
*** Bug 709544 has been marked as a duplicate of this bug. ***
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
that uses onmousewheel. It fails on Firefox 10.0.2.
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.
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?
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.
(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
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
> 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.
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):
and Firefox 19.0.2 passes all 3.
Interactive DOM 3 Events wheel (rolling) event properties webpage
(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
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
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?
> mousewheel.horizscroll.(modifier key).(type): see
> for more details.
(percent encoding of full stop required)
> Interactive DOM 3 Events wheel (rolling) event properties webpage
> (please do not bookmark this page as I may later filename-rename it.)
Interactive DOM 3 Events wheel (rolling) event properties webpage
is now at
and you can bookmark it!
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
(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
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
188.8.131.52 Event handlers on elements, Document objects, and Window objects
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.
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.
HTML spec doesn't define mousewheel event in any way. There is just onmousewheel property in GlobalEventHandlers.
> The fact is the official, final HTML 5 standard calls it "onmousewheel"
Fwiw, there is nothing even close to a "final HTML5 standard"....
D3E defines "wheel" event type but not "mouzewheel" event type.
onmousewheel should be dropped from HTML5 spec.
Additionally, we cannot implement mousewheel event because its delta value is different between all browsers which implement.
* 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.
> 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
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
> 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.
> 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
Anyone can tell me how IE11 preview handle such page ?
> "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.
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
> 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.