87
edits
Gecko:Mouse Wheel Scrolling: Difference between revisions
no edit summary
No edit summary |
|||
| Line 1: | Line 1: | ||
= Overview = | = Overview = | ||
Gecko can have multiple scrollable frames in its content. This documents the detail of mouse wheel scrolling rules in Gecko. | Gecko can have multiple scrollable frames in its content. This page documents the detail of mouse wheel scrolling rules in Gecko. | ||
This first version is written for Gecko 1.9.2. But this document isn't stable, so, when this document will be updated for new behavior, the writer must write the version clearly. | This first version is written for Gecko 1.9.2. But this document isn't stable, so, when this document will be updated for new behavior, the writer must write the version clearly. | ||
| Line 26: | Line 26: | ||
By above rules, users can scroll one scrollable frame smoothly. However, when two or more scrollable frames are nested, we need additional rules. | By above rules, users can scroll one scrollable frame smoothly. However, when two or more scrollable frames are nested, we need additional rules. | ||
For example, there is a page body which is scrollable and has a scrollable sub-frame (e.g., listbox of select element with multiple attribute, div element with overflow property, iframe element). When | For example, there is a page body which is scrollable and has a scrollable sub-frame (e.g., listbox of select element with multiple attribute, div element with overflow property, iframe element). When a user is scrolling down the sub-frame, it will be reached to the end of its content. However, some mouse wheel events which were fired after that will scroll the body unexpectedly. | ||
And there is another example, when the user is scrolling the page body, the sub-frame may come under the mouse cursor. Then, the sub-frame intercepts the mouse wheel events unexpectedly. | And there is another example, when the user is scrolling the page body, the sub-frame may come under the mouse cursor. Then, the sub-frame intercepts the mouse wheel events unexpectedly. | ||
| Line 44: | Line 44: | ||
* When a target frame is destroyed. | * When a target frame is destroyed. | ||
Note that the transaction is updated only when a mouse wheel event scrolls the target frame actually. I.e., when | Note that the transaction is updated only when a mouse wheel event scrolls the target frame actually. I.e., when a user keeps to turn mouse wheel to unscrollable direction, the transaction will be timed out. This is important for touchpad users, see [https://bugzilla.mozilla.org/show_bug.cgi?id=442774 bug 442774]. | ||
= | = DOM mouse wheel events and Scrolling and other default action = | ||
The specification of DOM Level 3 Events defines "wheel" event. We're working on this in [https://bugzilla.mozilla.org/show_bug.cgi?id=719320 bug 719320]. All web developers should handle only this event after it's fixed. | |||
And also, there are two legacy mouse wheel events which are non-standard. One is DOMMouseScroll event. This is typically fired when mouse wheel is turned one or more lines or pages. The other is MozMousePixelScroll. This event tells web applications how much pixels should be scrolled. It's typically fired after a DOMMouseScroll event, however, it may be fired before DOMMouseScroll event when native mouse wheel event causes less than one line or page on Windows. | |||
On Mac, native events tell Gecko how much lines should be scrolled first. After that, one or more native pixel scroll events may be fired for smooth scroll. Therefore, DOMMouseScroll event is fired first on Mac. | |||
Windows version of Gecko 1.9.2 and earlier doesn't fire | On Windows, native events tell Gecko how much lines or pages should be scrolled. If the scroll amount is not integer, Gecko dispatches a MozMousePixelScroll event first and stores the amount. When accumulated scroll amount becomes one or more, it dispatches DOMMouseScroll. | ||
On the other platforms, widget only dispatches DOMMouseScroll event and nsEventStateManager automatically dispatches MozMousePixelScroll event. | |||
If neither DOMMouseScroll nor MozMousePixelScroll is consumed by peventDefault(), nsEventStateManager performs a default action. There are four default actions: scroll, going back or forward history, zoom in or out, and doing nothing. | |||
So, the contents can prevent scrolling. Then, mouse wheel transaction isn't updated. | |||
Windows version of Gecko 1.9.2 and earlier doesn't fire DOM mouse wheel events when the mouse cursor is on a windowed plug-in and it consumes native mouse wheel events. This is going to be improved in [https://bugzilla.mozilla.org/show_bug.cgi?id=483136 bug 483136]. | |||
= Override system of system scroll speed = | = Override system of system scroll speed = | ||
| Line 95: | Line 103: | ||
* We don't send mouse wheel events to windowless plug-ins ([https://bugzilla.mozilla.org/show_bug.cgi?id=359403 bug 359403]). | * We don't send mouse wheel events to windowless plug-ins ([https://bugzilla.mozilla.org/show_bug.cgi?id=359403 bug 359403]). | ||
* When | * When a user is turning the mouse wheel but moving the mouse cursor, the transaction will not be finished even if the cursor is moved far. | ||
* When | * When a user finished scrolling a sub-frame but the sub-frame is clipped by its ancestor frame, the user doesn't still watch the all contents of the sub-frame ([https://bugzilla.mozilla.org/show_bug.cgi?id=428350 bug 428350]). | ||