| Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
(Not sure when this crept in.)
We need to ensure that we always generate the same hint strings for the
same filter state. Here, we do this by always using the same mechanism
(@filterLinkHints) to set the hint strings.
|
|
|
|
|
|
We gove these a higher score because it makes it easier for the user to
pick a link if they can just start typing at the beginning.
|
|
Thus, better matches are likely to either be first (so just hitting
<Enter> activates them) or just a <Tab> or two away.
Scoring:
- Requires that every search term be matched.
- Assigns higher scores to matches at the start of a word, and higher
scores still for whole-word matches.
|
|
|
|
|
|
|
|
|
|
Functionality wise, this is a no-op. However, since we now create a new
LinkHintsMode object on every "f", we don't need to be so careful about
resetting the state on exit.
|
|
|
|
|
|
|
|
See #1722.
When Settings.get("linkHintCharacters") is its default value, this
preserves the legacy behaviour of using the keyChar from keydown events
for link-hint matching. This admits users using either Latin or
non-Latin characters for link hints.
|
|
I think we can safely remove this comment now, @mrmr1993. This is
working out very nicely.
|
|
|
|
|
|
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.
|
|
On some keyboards (who knows?) "`" or "'" could be shift keys. In this
case, with the previous implementation, these would be treated as global
marks and `` would be unusable. This commit fixes that problem.
|
|
With global marks, we may later create a new tab when the mark is used.
When doing so, we should always be using the URL and scroll position of
the top frame within the tab. For example, if a global mark is created
from within the Hangouts frame of Google's Inbox and the mark is later
used, then we should create a new tab for Inbox's URL and scroll
position, not for the Hangout's URL and scroll position.
|
|
|
|
This should make link hints usable on non-Latin keyboards (e.g. Russian
keyboards).
Fixes #1387. (Maybe - because it's not clear from the discussion there
exactly what users want.)
|
|
|
|
As suggested by @mrmr1993 in #1716.
|
|
As suggested by @mrmr1993 in #1716.
|
|
On sites with several frames (e.g. Facebook), if we allow all of the
frames to handle the setScrollPosition and showHudForDuration messages,
then the focus ends up in an arbitrary frame. And, on Facebook, say,
Vimium ends up broken until the focus is returned to the main frame.
So, we only handle these messages in the main frame.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
... 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.
|
|
Fixes #1712:
- Make global marks work.
- Add mode indicator.
- Don't fail for global marks on background page if mark is not set.
- Give HUD warning for global marks if global mark is not set.
(The diff is big but, which the exception of infrastructure refactoring,
the main change is to not exit on <Shift>, thereby fixing #1712).
|
|
|
|
LinkHints.init() isn't doing anything.
|
|
This is a minor re-working of #1705 from @mrmr1993.
The main changes are:
- Simplify initialisation logic.
- Always initialise Settings immediately and automatically (ie. don't
initialise Settings separately and manually in the background,
content scripts, options and tests).
- Get rid of addEventListener (it's only being used for on "load").
- Add Settings.use() in its place.
|