385 bytes, text/html
4.06 KB, text/plain
31.40 KB, image/gif
9.94 KB, image/gif
71.39 KB, image/gif
654 bytes, text/html
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
http://bugzilla.mozilla.org/show_bug.cgi?id=179125#c3 joki is no longer here
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 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.
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.
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
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. 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.
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 :((.
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 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.
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
> 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 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
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?
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 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.
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.
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
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 > "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.
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
> 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)
> 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!
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
(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 18.104.22.168 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
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.
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.
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. http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html
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.
> 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