| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Conflicts:
background_scripts/main.coffee
content_scripts/vimium_frontend.coffee
lib/keyboard_utils.coffee
|
|
|
|
- implement "i", "a".
- fix "w" for edit mode.
- try out "e" for enter edit mode.
- initial implementation "o", "O"
- Suppress backspace and delete.
- Scroll in text areas.
|
|
This uses phantomjs to generate keyboard events. So the events are
propagated through the regular event listeners. So we're testing the
full keyboard-event flow.
|
|
- Set up modes such that they can be re-initialised.
- Move initialisation of BadgeMode to general initialisation function.
- Add reset() method for handlerStack.
- Consistently use initializeModeState() in all tests' setup().
- Refactor focusInput tests.
- Add some more tests.
- Simplify some other tests.
Note: Clean-up of the inputFocus overlay now happens when the exit()
method is called in Mode.reset(). This eliminates most needs to
artificially bubble a keyboard event to clear the overlay.
|
|
|
|
|
|
|
|
|
|
|
|
- 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.
|
|
- Better comments.
- Strip unnecessary handlers for leaving post-find mode.
- Simplify passKeys.
- focusInput now re-bubbles its triggering keydown event.
|
|
Slightly more significant:
Move several utilities to dome_utils.
|
|
In particular, this refactors the handling of non-vimium key events in
PostFindMode. This implements option 2 from #1415. However, #1415 is
not resolved, and option 3 remains a viable option.
|
|
- Slight rework of HandlerStack.
- Remove classs ExitOnEscape and ExitOnBlur
- Rework InsertMode, plus trigger and blocker.
- Remove StateMode.
- Do no mixin options.
- Lots of tidy up (including set a debug variable to Mode).
|
|
This begins work on addressing @philc's comments in #1413. That work is
nevertheless not yet complete.
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
As a proof of concept, this incorporates normal mode, passkeys mode and
insert mode.
|
|
|
|
Previously, handlerStack was designed only for removal of the handler
right at the top of the stack. However, some handlers sought to remove
themselves when they were not at the top of the stack, creating
confusion. The new handlerStack ensures that such removal can always be
done safely.
|
