| Age | Commit message (Collapse) | Author | 
|---|
|  | Launching link hints can sometimes be slow.  For filtered hints, the
user already knows what to type - but must nevertheless wait until the
hints have been calculated and rendered.
Here, we cache intervening keydown events, and replay them once
hints-mode proper is launched.  This should make improve usability (in
the case of filtered hints).
Fixes #3050. | 
|  |  | 
|  |  | 
|  | This is a workaround for Firefox bug 1408996. | 
|  |  | 
|  | This avoids the possibility of leaking keyup events if the keys a
released in a different order from that in which they were pressed.
Also, replace suppressKeyupAfterEscape with this same mechanism.
This fixes a bug (in master/1.59) whereby we leak the keyup event for
`i` when entering insert mode.
TODO:
- `/`, `<Escape>` leaks a keyup event
- `i` leaks a keyup event | 
|  |  | 
|  | Here's the problem...
Many sites define their own keyboard shortcuts, for example Google Play
Music defines `gh` for "go home".
On such sites, it's natural to set up pass keys for `g` and `h`.
But that makes any Vimium key bindings which begin with `g`
inaccessible.
Here, we add a new command `enterNormalMode` which installs a new
normal-mode instance (without any pass keys).  This executes a single
normal-mode command then exits.
Example:
    map \ enterNormalMode
    map | enterNormalMode count=999999
Assuming `g` and `o` are pass keys:
- `gh` or `o` - use the page's binding
- `\gg` - scroll to top
- `2\ggo` - scroll to the top and open the Vomnibar
- `\g<Escape>o` - open the Vomnibar
- `\<Escape>o` - use the page's bindings
- `\\\\\\<Escape>o` - use the page's bindings (new normal-mode instances
  displace previous ones)
This required some changes to the scroller.  Previously, we only ever
had one normal-mode instance, and could arrange statically that the
scroller's key listeners were above normal-mode's key listeners in the
handler stack.  Here, we fix this by adding and removing the scroller's
listeners dynamically, so they're always at the top of the handler
stack. | 
|  | This avoids initializing around 15 (almost all unused) HUDs on sites
like GMail and Google inbox.
Because the HUD is small, there is not noticable flicker. | 
|  | Problems:
  - The meanings of some of the Mode/handlerStack constant names is far
    from obvious.
  - The same thing is named different things in different places.
This changes various constant names such that:
  - the names used in the handler stack and in the modes are the same.
  - ditto vis-a-vis DomUtils.
Also, break out the core of the handler stacks' `bubbleEvent` method
into a switch statements.  This makes it more obvious that the cases are
mutually exclusive. | 
|  | Which:
  - uncovered a typo in 39adee9090fc5aadfd5dd681f91b80025084858a.
Also:
  - make Mode.debug a class variable, which is more helpful while trying
    to debug.  Specifically, you can turn debugging on or off from
    within the tests, for example. | 
|  | Because there is a small amount of time between link-hints mode being
requested and it being activated, it was possible to launch other Vimium
commands (e.g. the Vomnibar) after requesting link-hints mode, and
before link-hints mode starts.
This prevents that. | 
|  | While working on the visual-mode code, it became apparent that our
current "singleton" implementation is unnecessarily complicated.
This simplifies it.  The keys are now required to be strings.
(Previously, they could be any object; which meant we needed to gove
objects an identity.  All of which was complicated.) | 
|  | It makes more sense to pass the passKeys directly to normalMode.  So, do
so, and remove the trackState mode option - which isn't otherwise being
used. | 
|  |  | 
|  |  | 
|  | Miscellaneous fixes and tweaks, including:
- Reinstate key logging.
- Fix count handling in line with expected behaviour in #2024.
- Remove `noCount` option; we don't need it.
- Simplify logic in various places.
Fixes #2024. | 
|  | The styles guide says not to use standalone `@`.  So this changes the
occurrences I could find (with sed) to `this`.  Occurrences within files
with major outstanding PRs are omitted. | 
|  |  | 
|  |  | 
|  | We've been calling hintMode.exit() twice: once explicitly, and once as a
side effect of the simulated click event.
Since there are so many code paths through link hints, it seems better
to simply explicitly make mode.exit() idempotent for all modes.  Which
is what this commit does. | 
|  |  | 
|  | This ensures that -- on leaving link hints mode -- we consume any trailing keyup events (and don't let the underlying page see them).
Additional notes:
- There are other places where we seem to be leaking keyup events.
- A separate bug... It looks like we're calling `exit()` on link-hints
  mode twice. | 
|  | Exit on click because, if the user is clicking stuff, then they're
probably no longer interested in selecting links.
Exit on scroll because, if the user is scrolling, then the link hints
can all go out of the viewport. | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  | ... which is weird, because the tests are passing here.  Let's see what
Travis makes of this. | 
|  | It's pretty common that we want to suppress all keyboard events, so
let's support that in modes.coffee, thereby simplifying handlers
elsewhere. | 
|  | This turned out to be trickier than expected.  It turns out there's a
period after document.body is defined but before the DOM is ready when
we can't use the HUD (but previously thought we could, ie. HUD.isReady
returned true). | 
|  |  | 
|  |  | 
|  |  | 
|  | The page (or another extension) sees keydown events (such as shift)
before entering link-hint mode.  So we need to also pass the
corresponding keyup events.
Fixes #1522. | 
|  | Rationale.  There are really two insert modes: the one we activate with
"i" and the one that's activated when a focusable element receives the
focus.  This makes that distinction clearer.  And, in particular, it
means that, when the latter type of insert mode is active, we *know*
that gloabl insert mode is *not* active. | 
|  | The lack of a callback here was causing errors when loading (at least)
the options page. | 
|  | Conflicts:
	background_scripts/main.coffee
	content_scripts/vimium_frontend.coffee
	lib/keyboard_utils.coffee | 
|  |  | 
|  |  | 
|  |  | 
|  | - Use a has for singletons (as it was previously), but with a distinct
  identity generated by Utils.getIdentity.
- Fix counts not be using in a number of places. | 
|  | - Minor refactoring.
- Better selection of entity for "daw" an friends.
- dd uses count, and works for empty lines.
- Count for daw, etc.
- Fix bug whereby selection cleared when changing tabs. | 
|  | - Minor changes.
- Deactivate modes on inputs from focusInput(). | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  | - 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. | 
|  |  |