| Age | Commit message (Collapse) | Author |
|
Chrome has never searched in all frames, so this is no loss.
However, find on Firefox Quantum is now broken with the "all frames"
flag set.
Fixes #2962.
H/t: @gdh1995 (https://github.com/philc/vimium/issues/2962#issuecomment-367991086).
|
|
It appears that nobody is using this (and it is broken). So this PR
removes this feature.
Fixes #2937 (kind of).
|
|
Credit to @gdh1995 for catching these oversights.
|
|
This fixes #2757.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
This does NOT fix wrapping, only catches errors
|
|
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.
|
|
"/" followed immediately by "i" can hang Vimium.
The problem is that launching find mode is asynchronous (we wait until
the HUD is available). Because normal mode is still active, we can enter
insert mode *before* the find-mode HUD receives the focus.
The result is that we end up in both find mode and insert mode, the HUD
has the focus, but the HUD is in insert mode, so it ignores keyboard
events (including `Escape`).
The only way out is to click the page's body and then type `Escape`.
This commit demonstrates the problem: 7d2b00411eae3293fa4c7b1f61b384c0c495b5a2.
This happens in practice, for example while a busy page is loading.
This commit fixes this by ensuring that find-mode blocks keyboard events
immediately (and synchronously) on launch.
|
|
|
|
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.)
|
|
|
|
|
|
(We need to use "this" inside this function.)
|
|
|
|
|
|
The super-class's constructor sets @options, so we can't set it here;
instead, we pass the options along.
|
|
This code belongs together, so we put it together.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- 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 changes.
- Deactivate modes on inputs from focusInput().
|
|
|
|
|
|
- Mainly comments.
- Rename chooseBadge to updateBadge (for consistency).
- No badge for passkeys; also fix tests.
|
|
|
|
|
|
- refactor PostFindMode (to keep separate functionality separated).
|
|
|
|
|