We don't want to gesture activate for key and mouse/pointer events sent to
editable elements, as that would mean user interaction intended as text input
could start media playback, which would not likely be the user's intention.
MozReview-Commit-ID: VemPfpuziz
--HG--
extra : rebase_source : b2267f5ae2c9f0f6626f622bc98e3c5f18faf8bb
We don't want key presses of keys which are likely to be intended to be
interaction with the browser or OS to gesture activate documents and unblock
autoplay videos. So don't gesture activate for key events which are modifier
keys, or which don't have a pseudo char code.
MozReview-Commit-ID: 6uyPmlzbAvg
--HG--
extra : rebase_source : 8be949228b666a2ff54385f14b38b8f89459b1e2
extra : source : 59979388ba67d5fbfa8f3801bb65ac0fd2a49408
We don't want to gesture activate for key and mouse/pointer events sent to
editable elements, as that would mean user interaction intended as text input
could start media playback, which would not likely be the user's intention.
MozReview-Commit-ID: VemPfpuziz
--HG--
extra : rebase_source : b2267f5ae2c9f0f6626f622bc98e3c5f18faf8bb
We don't want key presses of keys which are likely to be intended to be
interaction with the browser or OS to gesture activate documents and unblock
autoplay videos. So don't gesture activate for key events which are modifier
keys, or which don't have a pseudo char code.
MozReview-Commit-ID: 6uyPmlzbAvg
--HG--
extra : rebase_source : 8be949228b666a2ff54385f14b38b8f89459b1e2
extra : source : 59979388ba67d5fbfa8f3801bb65ac0fd2a49408
We should gesture activate documents in key/mouse down instead of up because
if a web app wants to play a video inside a key/mouse handler, the document
needs to be activated before the handler runs.
Also, Chrome activates on key/mouse down, so we may have compat issues if
we have different behaviour.
MozReview-Commit-ID: JgGaQcNQfzz
--HG--
extra : rebase_source : edf5673be59a3714c3dd4eb239efd17d6a91ec32
We should gesture activate documents in key/mouse down instead of up because
if a web app wants to play a video inside a key/mouse handler, the document
needs to be activated before the handler runs.
Also, Chrome activates on key/mouse down, so we may have compat issues if
we have different behaviour.
MozReview-Commit-ID: JgGaQcNQfzz
--HG--
extra : rebase_source : de4269db9538e9c8aa5ff686c215bd619cf0c573
This method is not a virtual call, and also looks nicer.
This patch was mostly generated by a Python script, but I manually
cleaned up the code in a few places where statements didn't need to be
split across multiple lines any more.
MozReview-Commit-ID: 8JExxqSRc59
--HG--
extra : rebase_source : df6330a89e8d65dfe7a6fda0c8cb9f9732302efc
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 only introduces the concept and the functionality of retrieving the
values from the two new related prefs. Still no actual functionality change is
involved.
MozReview-Commit-ID: 2Gl3Wqdo6jL
--HG--
extra : rebase_source : bf30483e3e32829a5d6fd927740471ba348448f9
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
Calling GenerateDragGesture at this point should not be necessary, since
eTouchMove events are already handled in the same function. This code
is intermittently triggered through (what I can only call "rogue")
eMouseMove, ePointerDown and ePointerMove events, which is causing hangs
in the native DoDragDrop function further down the stack.
Arguably this shouldn't be triggered by e.g. ePointerDown either, and
I'm unclear on why exactly DoDragDrop is hanging (likely because it is
called again before the user does a drop), but this is a quick fix that
should be suitable for uplift.
MozReview-Commit-ID: A0hBlS85icx
--HG--
extra : rebase_source : 4d26c92c556068fc25dca5ad5d106187274b3e2a
And then fix up everything else that needs to change as well.
MozReview-Commit-ID: GDMfERqdQAc
--HG--
extra : rebase_source : 01fe06c3182245a409099a53383d92bf4fa0155c
The change from "docShell" to "mDocShell" for the SetName call in the
OwnerIsMozBrowserFrame case in nsFrameLoader::MaybeCreateDocShell is a
drive-by correctness fix for a bug the rename of "docShell" to "parentDocShell"
caught: setting the name of our _parent_ docshell based on the name attr of our
owner makes no sense.
MozReview-Commit-ID: DwnWt8jTokV
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
Most of them just want GetRootFrame(), and there's no need to explicitly go
through the frame manager for that, we have a handy alias in the shell.
MozReview-Commit-ID: GriEqkasidY
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
