| Age | Commit message (Collapse) | Author |
|---|
|
This reinstates the feature whereby we disable the content script when
we lose contact with the background page, e.g., on upgrade.
From my investigations, this doesn't appear to be absolutely necessary.
Nevertheless, it's cleaner like this.
|
|
Normal mode updates the pass keys every time the frame changes (so, also
every time we change tab). Here, we reset the key state too. Resetting
the key state makes sense when, for example, the user has changed the
pass keys. However, it also changes a status quo/master behaviour:
- `g`, change-tab-with-mouse, change-back, `g` -- previously this
scrolled to top; now it does not.
|
|
This reinstates the legacy behaviour in the following case:
- `g`
- change tab
- change back to the original tab
- `g`
- ..... which scrolls to top.
It is not obvious that this is the best behaviour, but it is the legacy
behaviour, and it certainly isn't unreasonable.
|
|
- remove unused "event" parameter
- move methods around to put like with like
- simplify some expressions
- one better method name
|
|
|
|
|
|
|
|
|
|
- simplify pass key condition
- don't keep key-parsing Regexp in memory
- we should reset the key state when the pass keys change
|
|
|
|
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.
|
|
|
|
Previously, the key-handling logic (keyQueue, etc) was and the backend
whereas passKeys were handled in the content scripts - so they were a
long way apart.
Now that they're in the same place, it makes more sense to integrate
passKey handling into the regular key handling, because they depend upon
the same data structures.
|
|
|
|
|
|
|
|
... and fix two bugs:
- not suppressing keyup event after keyChar matched in keydown.
- we cannot check the passKeys keyChar in keyup because the key state
has changed; so we track what the next keyup response should be.
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This implements a generic front-end class for key handling (a la normal
mode). Also:
- supports count prefixes (or not)
- supports multi-key mappings (longer than two)
Also included is a very poor-man's demo. See the bottom of
mode_key_handler.coffee for some hard-wired key bindings.
IMPORTANT:
This does not actually work as Vimium. It's just a demo.
|
|
The options page receives messages intended for the background page (and
we're getting console warnings). This is a more general test for when
the front end should ignore such messages.
Fixes #2034.
|
|
A small refactor link hints.
|
|
- The check for whether a rect is defined is only used in one of the
three cases. So we don't need it.
- Also, better veriable name.
|
|
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.
|
|
|
|
Previously, we set a variable `delay` and then did some logical
gymnastics to get the correct effect.
However, in fact, all we care about is whether the user might over-type
the links text. So changing to using that as a Boolean flag greatly
simplifies the logic. And we lose about 10 LoC.
|
|
While we're changing this code, we can renamed the parameter here to be
consistent with its naming elsewhere.
|
|
Somehow,
|
|
Previously (quite some time ago) we reused the LinkHints object. But
for some time it's been a class, and we never reuse instances.
Therefore, we can remove the code related to resetting the object's
state.
|
|
Previously, the exit sequence when a link was "clicked" was spread over
several functions with several callbacks. This made it difficult to
verify that the correct actions were happening in the correct order.
Indeed, they weren't in at least one case (we were still showing hints
while "waiting for enter").
This fixes that by putting all of the various deactivation orders into
one place, `@activateLink()`, and simplifies `@deactivateMode()`
accordingle.
|
|
|
|
We were immediately restarting link-hints mode if a count was present.
Unfortunately, that meant that we were detecting our own link-hint click
and exiting immediately. So, with a count of 6, we were only getting 3
link-hint activations.
To avoid this, we add a short delay (just nextTick).
Also, move some other stuff arund to make sure this works in all cases
(e.g. wait-for-enter).
|
|
Refactor focusFrame - Fix #2023.
|
|
Only the `flashFrame` part needs to be guarded against the DOM being
ready. So we can take the `flashFrame` part out as a regular function.
Fixes #2023 (although I don't fully understand why that's happening).
|
|
Currently, `10j` keeping `j` held down scrolls quickly for a time then
reduces back the regular hold-`j` scroll speed. Therefore, the user
cannot use a count to influence the smooth-scrolling scroll speed.
This PR fixes that by passing the count to the scroll functions.
Consequently, we adjust the actual scroll amount (which affects the
scroll speed) rather than calling the scroll commands several times
(which doesn't).
|
|
|
|
Omitted from #1961.
|
|
If text.length is 1, here, then we divide by `log 1` - which is zero.
So add one.
|
|
It appears `tabInfoMap` (and related machinery) is not being used. This
removes it.
|
|
When we introduced command options (for mapping keys to custom-search
engines), the parsing was done in the Vomnibar code.
This moves the parsing to `commands.coffee`, which is where it should
always have been.
This is a preliminary step with a view to adding a new `count` command
option.
|
|
This makes the `hideHud` option apply only to insert mode (when entered with `i`).
Fixes #1953.
Fixes #487.
We could rename the option itself and add migration code, but that seems overkill.
An alternative would be to remove this option entirely.
|
|
|
