aboutsummaryrefslogtreecommitdiffstats
path: root/content_scripts/mode_insert.coffee
diff options
context:
space:
mode:
authorStephen Blott2015-01-10 08:25:02 +0000
committerStephen Blott2015-01-10 11:03:01 +0000
commitfdcdd0113049042c94b2b56a6b716e2da58b860e (patch)
tree5cbeacce234df58fc1f5c125f2055a591578a510 /content_scripts/mode_insert.coffee
parentac90db47aa2671cd663cc6a9cdf783dc30a582e9 (diff)
downloadvimium-fdcdd0113049042c94b2b56a6b716e2da58b860e.tar.bz2
Modes; instrument for debugging...
- Set Mode.debug to true to see mode activation/deactivation on the console. - Use Mode.log() to see a list of currently-active modes. - Use handlerStack.debugOn() to enable debugging of the handler stack.
Diffstat (limited to 'content_scripts/mode_insert.coffee')
-rw-r--r--content_scripts/mode_insert.coffee20
1 files changed, 11 insertions, 9 deletions
diff --git a/content_scripts/mode_insert.coffee b/content_scripts/mode_insert.coffee
index 144b0be6..7668d794 100644
--- a/content_scripts/mode_insert.coffee
+++ b/content_scripts/mode_insert.coffee
@@ -51,6 +51,7 @@ class InsertModeTrigger extends Mode
@stopBubblingAndTrue
@push
+ _name: "mode-#{@id}/activate-on-focus"
focus: (event) =>
triggerSuppressor.unlessSuppressed =>
@alwaysContinueBubbling =>
@@ -78,6 +79,7 @@ class InsertModeBlocker extends Mode
@onExit -> triggerSuppressor.unsuppress()
@push
+ _name: "mode-#{@id}/bail-on-click"
"click": (event) =>
@alwaysContinueBubbling =>
# The user knows best; so, if the user clicks on something, the insert-mode blocker gets out of the
@@ -92,18 +94,18 @@ class InsertModeBlocker extends Mode
new @options.onClickMode
targetElement: document.activeElement
-# There's some unfortunate feature interaction with chrome's content editable handling. If the selection is
-# content editable and a descendant of the active element, then chrome focuses it on any unsuppressed keyboard
-# event. This has the unfortunate effect of dropping us unintentally into insert mode. See #1415.
-# A single instance of this mode sits near the bottom of the handler stack and suppresses keyboard events if:
-# - they haven't been handled by any other mode (so not by normal mode, passkeys mode, insert mode, and so
-# on),
+# There's some unfortunate feature interaction with chrome's contentEditable handling. If the selection is
+# contentEditable and a descendant of the active element, then chrome focuses it on any unsuppressed keyboard
+# event. This has the unfortunate effect of dropping us unintentally into insert mode. See #1415. A single
+# instance of this mode sits near the bottom of the handler stack and suppresses keyboard events if:
+# - they haven't been handled by any other mode (so not by normal mode, passkeys, insert, ...),
# - the selection is content editable, and
# - the selection is a descendant of the active element.
# This should rarely fire, typically only on fudged keypresses in normal mode. And, even then, only in the
# circumstances outlined above. So, we shouldn't usually be blocking keyboard events for other extensions or
# the page itself.
-# handling keyboard events.
+# There's some controversy as to whether this is the right thing to do. See discussion in #1415. This
+# implements Option 2 from there, although Option 3 would be a reasonable alternative.
new class ContentEditableTrap extends Mode
constructor: ->
super
@@ -112,10 +114,10 @@ new class ContentEditableTrap extends Mode
keypress: (event) => @handle => @suppressEvent
keyup: (event) => @handle => @suppressEvent
- handle: (func) -> if @isContentEditableFocused() then func() else @continueBubbling
+ handle: (func) -> if @wouldTriggerInsert() then func() else @continueBubbling
# True if the selection is content editable and a descendant of the active element.
- isContentEditableFocused: ->
+ wouldTriggerInsert: ->
element = document.getSelection()?.anchorNode?.parentElement
return element?.isContentEditable and
document.activeElement and