| Age | Commit message (Collapse) | Author |
|---|
|
Exit link hints if there are no links.
|
|
If there are no links on a page, then link-hints mode should exit immediately.
Fixes #1395.
|
|
Do not exit link-hints mode on scroll.
|
|
Fixes #1918.
|
|
|
|
Simplify hint string generation
|
|
|
|
|
|
|
|
|
|
|
|
This applies only to the case where visual mode is run under edit mode.
Previously, we were leaving the selection in place ... which is weird
and not vim-like.
|
|
|
|
For some (unknown) reason, we do not receive the keyup event for Shift
when activating link hints. Consequently, we are not correctly removing
the keyup handler. And that handler is blocking subsequent keyup
events, which has the effect of endless scrolling (because the scroller
relies on keyup events to stop scrolling).
Here, we correcttly remove the keyup handler when link-hints mode exits.
Fixes #1911.
|
|
|
|
smblott-github/better-delay-for-filtered-link-hints
Block keyboard events when a filtered hint matches.
|
|
Suppress trailing key events (after link hints).
|
|
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.
|
|
|
|
Previously, we blocked keyboard events for a fixed 200ms.
With this PR, we continue blocking keyboard events until 150ms after the
last `keydown` or `keypress` event. So, we wait until we think the user
has stopped typing.
Fixes #1842.
|
|
|
|
Rework to make match counting code for searches more DRY and easier to read
|
|
|
|
|
|
Don't show UIComponent <iframe>s while vimium.css loads
|
|
|
|
|
|
This fixes #1817, where our stylesheet isn't loaded correctly due to a
Chromium issue and the Vomnibar/HUD <iframe>s are always visible on the
new tab page.
|
|
|
|
|
|
JavaScript's sort function is not stable; this PR makes the sort used for filtered link hints stable.
There are two reasons for doing this:
- High-scoring hints are more likely to keep the same hint string as the user continues typing. (Currently, the hints assigned change based on the vaguaries of the non-stable sort.)
- For equal-scoring hints, we retain the visit-child-before-parent ordering (which is used to NOT match a parent's text if we have already matched that text in a child).
And, as a result of all of that, the UX is more predictable and hence better.
|
|
|
|
Only apply passkeys to single character keys explicitly
|
|
|
|
|
|
|
|
|
|
|
|
This implements @gdh1995's idea from #1796.
|
|
If we miss the keyup event while a smooth scroll is active (because the
focus changes), then we scroll forever. This stops scrolling on blur.
Fixes #1788.
|
|
Add support for ngClick to link hints
|
|
|
|
Before this change, a string in KeyboardUtils.keyNames could have the
key it represents disabled if
* its letters were in alphabetical order, and
* the user has set all of its letters as passkeys, with none in between.
For example, imagining that "del" (for delete) was in
KeyboardUtils.keyNames, the passkeys "dpyl0e" would cause the delete key
to be a passkey too.
This commit fixes the issue by only applying passkeys when keyChar is a
single character.
|
|
|
|
See @mrmr1993's comment in 2cc7dc1d2164b5dbb27bcc1d4bc0517402dd7581.
|
|
Re-working of @poacher2k's ideas from #1745.
- check whether AngularJS is being used.
- avoid building the AngularJS attribute strings multiple times.
- avoid building them *at all* if AngularJS is not being used.
|
|
(We need to use "this" inside this function.)
|
|
|
