Open Bug 543338 Opened 15 years ago Updated 2 years ago

Wrong .detail is reported in DOMMouseScroll events

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Platform:
x86
All
Type:
defect

Tracking

()

People

(Reporter: smaug, Unassigned)

References

Details

Since we have the strange scroll acceleration code when user has the default (3?) line scrolling, we actually scroll more lines than what DOMMouseScroll.detail reports.
No, we don't modify the value by our acceleration and override code. I think that this is better for backward compatibility of web applications. And it's pretty difficult that we modify the value because the scrolling computation will be done *after* DOMMouseScroll event handling. https://wiki.mozilla.org/Gecko:Mouse_Wheel_Scrolling
Note that there are other problems: 1. The target is difficult when the transaction system uses another target instead of a scrollable frame under the cursor. 2. Even if we limit the scroll amount to lesser lines than the native event at the scrollable view is too small, we've never changed the DOMMouseScroll event information.
I guess one thing to test is that what does webkit/Chrome do here with mousewheel event.
I tested on Google Chrome 4: > data:text/html,<body style="white-space: pre;" onload="document.addEventListener('mousewheel', function (e) { var n = document.createTextNode('wheelDelta=' + e.wheelDelta + '\n'); document.body.insertBefore(n, document.body.firstChild); }, false);"><div style="height:5000px;"></div></body> The wheelDelta value has native delta value. So, we don't have compatibility. # our delta value has line count. I think that DOMMouseScroll event's delta value should be consistent for the native event. If that should have actual scrolling line count, we should set zero if there are no scrollable frames. Of course, I don't think so. Our overriding, acceleration and limitation of scrolling amount systems are just change the meaning of delta value. I.e., it changes an interpretation of delta value, not changes the actual value. So, they are similar to page scrolling mode. So, I think this bug should be marked as INVA. If web developers need to know the actual scrolling amount, they should listen scroll event and check the scrollTop, scrollLeft properties.
(In reply to comment #4) > The wheelDelta value has native delta value. So, we don't have compatibility. > # our delta value has line count. I meant, does Chrome change the wheelDelta because of the acceleration? > Our overriding, acceleration and limitation of scrolling amount systems are > just change the meaning of delta value. This is true. > So, I think this bug should be marked as INVA. Could be. I filed this bug while testing our behavior for DOM 3 Events. That draft specifies new wheel events, and DOMMouseScroll/MozPixelScroll and mousewheel event are going to be deprecated. Luckily the new model is pretty close to gecko's mouse wheel handling.
(In reply to comment #5) > (In reply to comment #4) > > The wheelDelta value has native delta value. So, we don't have compatibility. > > # our delta value has line count. > > I meant, does Chrome change the wheelDelta because of the acceleration? I can say no. The wheelDelta is a raw data. So, their acceleration is also the interpretation level behavior. I guess that they use a fixed line-height for mouse wheel events rather than the actual line-height of the scrollable frame.
There is an interesting issue on Google Chrome. As I said, Chrome sets native delta value to wheelDelta. The delta value doesn't mean the count of lines. On Windows, we need to compute the amount of scroll lines with registry value. See: http://mxr.mozilla.org/mozilla-central/source/widget/src/windows/nsWindow.cpp#5234 So, Google Chrome's wheelDelta value doesn't mean the scrolling amount. It just means amount of wheel rotation. I.e., the wheelDelta value isn't changed by the system settings. Therefore, web developers cannot know the scrolling amount on Chrome.
DOM3 Events has the wheel event which can be used for pixel, line or page scrolling.
Yeah, I know. I think that W3C should define the order of DOM3 wheel events and actual scrolling. If our order --- dispatching DOM wheel events first, scrolling (or another action) an element after that --- will be preferred, the spec should say that the delta value can be different from the actual scrolling amount. I recommend our behavior because: 1. The DOM wheel event handlers can prevent the default behavior (e.g., scrolling, zooming) on any elements (not only on the target). 2. We cannot know the actual scrolling target when dispatching DOM wheel events. So, we can set a consistent delta value for same action. (If we set guessed value, it causes inconsistent delta value even if the user did same action. E.g., our scroll speed overriding system doesn't accelerate scrolling on non-root scrollable view.) And also it's not clear that whether untrasted wheel event can scroll or not.
Component: Event Handling → User events and focus handling
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.