Revise handler stack implementation.

The old implementation:
- Wasn't actually checking whether handlers had been removed before
  calling them.
- Could end up calling the same handler twice (if a handler was removed
  further down the stack, and the stack elements moved due the resulting
  splice.

Solution:
- Mark elements as removed and check.  Set their ids to null.
- Don't splice stack.

Also, optimisation:
- Removing the element at the top of the stack is still O(1).
- In Modes, reverse handlers before removing (so, more likely to hit the
  optimisation above).

For the record, the stable stack length at the moment seems to be about
10-12 elements.

1 files changed, 3 insertions, 1 deletions

diff --git a/content_scripts/mode.coffee b/content_scripts/mode.coffee
index 10b7bb2a..76b65a12 100644
--- a/content_scripts/mode.coffee
+++ b/content_scripts/mode.coffee
@@ -76,7 +76,9 @@ class Mode
 
   exit: ->
     console.log @count, "exit:", @name
-    handlerStack.remove handlerId for handlerId in @handlers
+    # We reverse @handlers, here.  That way, handlers are popped in the opposite order to that in which they
+    # were pushed.
+    handlerStack.remove handlerId for handlerId in @handlers.reverse()
     Mode.modes = Mode.modes.filter (mode) => mode != @
     Mode.updateBadge()