| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
This was broken by the move to taking input in an iframe, since the
frontend was no longer getting keydown events for text changes, and so
the viewport wasn't being scrolled back to its original position until
the mode was exiting.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This keeps searches with trailing spaces from missing matches where the
page contains normal spaces, preventing " (No matches)" being shown
every time space is pressed.
|
|
|
|
|
|
|
|
|
|
|
|
(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 that page, we have regular expressions (which are not new-user
friendly) and an example (which is new-user friendly). So the example
should come before the regular expressions.
|
|
With #1697, the vomnibar used with a custom-search keyword is not
initially empty (it shows the primary suggestion for the custom search
engine, even if the query is empty). The way things were structured
previously, the user nevertheless had to wait until the history cache
(which was not actually required) had been fetched before the vomnibar
was updated.
This commit just flips things around a bit such that,
- onComplete() is called immediately if the history is not actually
required, and
- the history cache is primed before it is needed, so it will
(hopefully) be available before the user's next keystroke.
This avoids a noticable delay, particularly on start up and with a large
history.
(This is part of a sequence of vomnibar UX tweaks.)
|
|
Conflicts:
background_scripts/completion.coffee
background_scripts/completion_engines.coffee
|
|
On the help page, use separate row for very-long bindings.
|
|
When filter suggestions from other completers, most notably the history
completer, we only keep suggestions which match the current searchUrl
and completer. Here, we also *replace* the URL of the suggestion. With
duplicate elimination, multiple history entries (e.g. those generated
with various "Search Tools" settings on Google) will be collapsed to
one. This matters because, with custom search engines, we don't show
the URL, so the user can't see differences in the URL. Without this,
the user can be presented with a list of apparently identical
completions.
|
|
This commit contains the bulk og the material changes for which the
previous commits established the basis.
1) Add a general framework for detecting query prefixes in search URLs,
adding them to query sent to the completion engine, and stripping them
from the resulting suggestions. This allows the user to have a
search engine...
j: http://www.google.com/search?q=javascript+%s Javascript
and have the prefix "javascript" included (automatically) in queries
sent to completion engines, which results in substantially better
suggestions.
2) Re-work completion for Google Maps in a simpler form.
|
|
|
|
The original completion-engine interface was based on three functions.
With some experience, it seems there is a pattern involving explicit
regular expressions which is used by all actual engine implementations.
This is a refactoring to make those regular expressions explicit (and
required), and is a first step towards adding additional fucntionality.
This also simplifies the completion cache key (use JSON instead of some
weird hash).
|
|
|
|
Improved global marks
|
|
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.
|
