With this commit, all the auto-dir scrolling functionalities are completed in
non-APZ.
MozReview-Commit-ID: 9v9iPWIwB52
--HG--
extra : rebase_source : 9c825ed6ebcd84a90057bcb9d301838014c181d8
This commit implements the auto-dir scrolling functionality in non-APZ, based on
part 1 to part 3. However, the functionality of mousewheel.autodir.honourroot is
unimplemented in this commit.
MozReview-Commit-ID: 2vYABOx4RkK
--HG--
extra : rebase_source : 7dc45e6747a101c1a2c3a22bc695b2a0b2494b50
This commit defines a common interface of the auto-dir scrolling functionality.
In future commits, it will be implemented in both the APZ and non-APZ parts.
MozReview-Commit-ID: 8fApuHwsbrv
--HG--
extra : rebase_source : e4c47ea52c1c9c60822b23216db020154522bb7e
Do some work in preparation for implementing actual functionalities for this
bug. No actual functionality change is involved in this commit.
MozReview-Commit-ID: 5aLhr38n1N4
--HG--
extra : rebase_source : 15cfc2cea5b7668367dd3bd4a0746ae8c61b7d20
Unlike a DOM wheel event listeners which receive original delta values, plugins
receive horizontalized ones. It's not reasonable to not send original values to
plugins.
Plugin developers can do any delta adjustment, and they are also capable of
DIRECTLY getting what inputs the user is manipulating, that is to say,
developers can horizontalize scrolling for [Shift+Vertical Wheel] or other other
inputs if they want, it's just their matter; conversely, they aren't capable of
getting what delta adjustment their upstream has already encapsulated for them.
So it's not reasonable to send adjusted delta values to plugins.
This patch restores horizontalized delta values to the original for plugins.
MozReview-Commit-ID: IX8XJn0lbKq
--HG--
extra : rebase_source : ea9abef4706701e2c43ee06563bd10bc0a863614
As for now, the scrollable direction with a mouse wheel for a single-line text
control is hard-coded; that is, only horizontal wheel scrolls are able to take
effect while vertical ones aren't. However, this isn't the desired case for
vertical writing mode, where the opposite case definitely suits better.
This commit refines the hard-coded scrollable direction for a single-line text
control to be writing-mode-adaptive.
MozReview-Commit-ID: 4Zkoe2ExPCZ
--HG--
extra : rebase_source : 113b2ea80b6bbbcd2d8379b438de97eedd616551
This patch declares a new default action, "horizontal scroll", this scrolls
content horizontally with deltaY of wheel events and ignores deltaX and deltaZ.
This is used for default action with Shift key in default setting except on
macOS. On macOS, legacy mouse's vertical wheel operation with Shift key causes
native horizontal wheel event. Therefore, we don't need to use this new
default action on macOS. Additionally, old default action with Shift key,
navigating history, is moved to with Alt key. This makes same settings between
macOS and the others. So, this is better for users who use macOS and another
OS and web app developers who check wheel events only on macOS or other
platform(s).
For simpler implementation, default action handlers moves deltaY values to
deltaX values temporarily *only* while they handle wheel events. This is
performed by AutoWheelDeltaAdjuster and restored after handling it
automatically.
So, in other words, even if default action is "horizontal scroll", web apps
receives wheel events whose deltaY is not zero but its content will be
scrolled horizontally. This is same as Chromium, so, this behavior shouldn't
cause any incompatible behavior with it.
MozReview-Commit-ID: E4X3yZzLEAl
--HG--
extra : rebase_source : e20d854c6b0a181ad4c9e7304bd9ad14256481ff
After click events with button 2 or 3 are fired, fire auxclick, a new
event intended to represent a non-primary mouse click. Because this
event, based on the design examples and blink's implementation, is
intended to be used with content listeners, always dispatch on content
listeners--not just those that force all events to be dispatched (i.e.
document/window). This diverges from the behavior of our click events
from non-primary buttons.
Eventually, we hope this will replace click events for non-primary
buttons. For now, leave those events for compatibility reasons.
Additionally, add handling of this new event, where necessary.
MozReview-Commit-ID: 8osozM4h6Ya
--HG--
extra : rebase_source : 558261dd0d0b9241efa84ca168c50455850af03a
The new name makes the sense of the condition much clearer. E.g. compare:
NS_WARN_IF_FALSE(!rv.Failed());
with:
NS_WARNING_ASSERTION(!rv.Failed());
The new name also makes it clearer that it only has effect in debug builds,
because that's standard for assertions.
--HG--
extra : rebase_source : 886e57a9e433e0cb6ed635cc075b34b7ebf81853