Closed
Bug 111647
Opened 22 years ago
Closed 5 years ago
onmousewheel event
Categories
(Core :: DOM: Events, enhancement, P3)
Core
DOM: Events
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: jay, Unassigned)
References
()
Details
(Keywords: testcase)
Attachments
(6 files, 1 obsolete file)
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.
Reporter | ||
Updated•22 years ago
|
Severity: normal → enhancement
![]() |
||
Updated•22 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Reporter | ||
Comment 1•22 years ago
|
||
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
Updated•22 years ago
|
Target Milestone: --- → mozilla1.1
Updated•22 years ago
|
OS: Linux → All
Hardware: PC → All
Updated•21 years ago
|
Priority: -- → P3
http://bugzilla.mozilla.org/show_bug.cgi?id=179125#c3 joki is no longer here
Assignee: joki → saari
QA Contact: vladimire → ian
Reporter | ||
Comment 3•20 years ago
|
||
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
![]() |
||
Updated•20 years ago
|
Target Milestone: Future → mozilla1.1alpha
Comment 5•20 years ago
|
||
We already have a "DOMMouseScroll" event. Does that just need to be hooked up to the onmousewheel attribute?
Comment 6•20 years ago
|
||
See bug 108757 for the DOMMouseScroll event patch.
Comment 7•19 years ago
|
||
The new design at http://www.ld4all.com is broken because of this. Hoping this can be made soon.
Comment 8•19 years ago
|
||
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•19 years ago
|
||
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•19 years ago
|
||
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.
Reporter | ||
Comment 11•19 years ago
|
||
Reporter | ||
Comment 12•19 years ago
|
||
Reporter | ||
Updated•19 years ago
|
Attachment #168204 -
Attachment is obsolete: true
Reporter | ||
Comment 13•19 years ago
|
||
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•19 years ago
|
||
Can this be reassigned to somebody who isn't gone? I wouldn't expect this to be hard to implement...
Comment 15•19 years ago
|
||
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.
Keywords: testcase
Whiteboard: http://www.gtalbot.org/Bugzilla/Bug111647.html WORKSFORME
Comment 16•18 years ago
|
||
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•18 years ago
|
||
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•18 years ago
|
||
After a quick chat with I. Hickson, I am resolving this bug as WORKSFORME
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME
Comment 19•18 years ago
|
||
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•18 years ago
|
||
Comment 21•18 years ago
|
||
Comment 22•18 years ago
|
||
Comment 23•18 years ago
|
||
Comment 24•18 years ago
|
||
> 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•18 years ago
|
||
> 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•18 years ago
|
||
*** Bug 291038 has been marked as a duplicate of this bug. ***
Comment 27•18 years ago
|
||
(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
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Comment 28•18 years ago
|
||
(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•18 years ago
|
||
> 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
Reporter | ||
Comment 30•18 years ago
|
||
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•18 years ago
|
||
Logically the handler would be called "onDOMMouseScroll" as the event we support is "DOMMouseScroll", which is not standard...
Assignee: saari → events
Status: REOPENED → NEW
Updated•18 years ago
|
Whiteboard: http://www.gtalbot.org/Bugzilla/Bug111647.html WORKSFORME
Comment 32•18 years ago
|
||
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.
Updated•18 years ago
|
Status: NEW → RESOLVED
Closed: 18 years ago → 18 years ago
Resolution: --- → WORKSFORME
Comment 33•18 years ago
|
||
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.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Reporter | ||
Comment 34•16 years ago
|
||
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
Status: REOPENED → RESOLVED
Closed: 18 years ago → 16 years ago
Resolution: --- → WONTFIX
Comment 38•12 years ago
|
||
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.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Updated•12 years ago
|
![]() |
||
Comment 39•12 years ago
|
||
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•12 years ago
|
||
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.
Updated•12 years ago
|
Assignee: events → nobody
QA Contact: ian → events
Target Milestone: mozilla1.1alpha → ---
Comment 41•10 years ago
|
||
(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•10 years ago
|
||
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•10 years ago
|
||
> 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•10 years ago
|
||
> 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•10 years ago
|
||
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•10 years ago
|
||
(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
Status: REOPENED → RESOLVED
Closed: 16 years ago → 10 years ago
Resolution: --- → FIXED
Summary: onmousewheel event → DOM 3 wheel event support
Comment 47•10 years ago
|
||
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•10 years ago
|
||
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Summary: DOM 3 wheel event support → onmousewheel event
Comment 49•10 years ago
|
||
HTML spec doesn't define mousewheel event in any way. There is just onmousewheel property in GlobalEventHandlers.
![]() |
||
Comment 50•10 years ago
|
||
> 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•10 years ago
|
||
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•10 years ago
|
||
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•10 years ago
|
||
> 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
Updated•10 years ago
|
Keywords: dev-doc-needed
Updated•10 years ago
|
Comment 54•5 years ago
|
||
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)
Status: REOPENED → RESOLVED
Closed: 10 years ago → 5 years ago
Resolution: --- → WONTFIX
Updated•5 years ago
|
Keywords: dev-doc-needed
You need to log in
before you can comment on or make changes to this bug.
Description
•