From fdcdd0113049042c94b2b56a6b716e2da58b860e Mon Sep 17 00:00:00 2001
From: Stephen Blott
Date: Sat, 10 Jan 2015 08:25:02 +0000
Subject: 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.
---
 content_scripts/mode_insert.coffee | 20 +++++++++++---------
 1 file changed, 11 insertions(+), 9 deletions(-)

(limited to 'content_scripts/mode_insert.coffee')

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
-- 
cgit v1.2.3