| Age | Commit message (Collapse) | Author |
|---|
|
|
|
With a count, link hints now exit on `Escape`.
|
|
|
|
Currently, if an input is only partially in the view port, then the page
may scroll when it is focused and the overlays for `focusInput()` are
wonky. See #1257.
Here, we draw the overlay around the *entire* input, instead of just
around the visible part. Being partially visible therefore is no longer
relevant.
Fixes #1257.
Closes #1258.
|
|
|
|
Pass a count to link-hint commands, and the link-hint mode is started that many times (except "with queue").
This resolves the same issue as #1291. However, this:
- does not require re-basing (which is no biggie), and
- keeps all of the count-handling logic (apart from plumbing) in one
place, in `LinkHints.activateMode()`. The link-hints mode itself does
not know anything about count handling.
Serious bug:
- Using `Escape` to exit does not cancel the repeat!
Fixes #1289.
Closes #1291.
|
|
|
|
One line was unintentionally deleted.
|
|
I am now of the opinion that we should not do this within Vimium, as:
- better solutions exist externally, and
- it's better to not have to maintain this.
|
|
It is often the case that an encosing element (parent) and a child are
both clickable, and both contain the same text. In this case, it is
usually better to pick the child.
So, here, we dampen down the score of elements with longer texts.
|
|
Emit mouseout for the last link when clicking a new link with link hints
|
|
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
|
|
|
