| Age | Commit message (Collapse) | Author |
|---|
|
This causes `o`/`O` to crash (producing no suggestions).
As a workaround, set any such title to "".
|
|
This affects binary search in the history cache.
The returned index can be one beyond the end of array, and so we get an
error when we look it up blindly. So, we need to check.
|
|
We do not need "displayUrl", we can re-use "shortUrl" instead. It does
what we need already.
|
|
|
|
We only match the text "javascript:...".
The affects only the bookmark completer.
|
|
Show "javascript:" URLs as "javascript:...".
Fixes #961.
|
|
|
|
Certain background-page utilities are actually shared, and are therefore
best placed in place that reflects that.
Here, tabRecency is moved to the new gb_utils.coffee in preparation for
implementing a go-to-previous-tab command. In particular, it is no
longer appropriate that tabRecency be embedded within the completion
code.
logMessage() from main.coffee is also a candidate for moving to
bg_utils.coffee.
|
|
|
|
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
|
|
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.
|
|
When the user changes custom search engine during a single vomnibar
activation, we should only offer suggestions which match the current
search engine (not the previous one).
We now do this not just by checking that the suggestion is a custom
search suggestion, but by checking that the actual search URL matches.
|
|
In Google Maps, we get a new history entry for every pan and every zoom.
This removes such duplicates.
|
|
This will allow us to use the same search-engine parsing code in the
background page and in content scripts.
|
|
completion-on-custom-search-only-merge
Conflicts:
background_scripts/completion.coffee
|
|
In omni mode, the vomnibar suggestions are updated asynchronously.
Therefore, the contents of the primary custom search-engine suggestion
may be behind the actual contents of the comnibar input. So, we
reconstruct the custom search-engine query on "enter".
(This fixes a long-standing race condition.)
|
|
This optimisation is now unnecessary, because we will *always* show at
least one completion suggestion in top spot.
|
|
This ensures that <Tab> can always be used to complete the top-ranking
completion.
|
|
This option is no longer needed, since we don't do search completion
except for custom searches.
|
|
|
|
|
|
Also suppress highlighting of matching text in previous suggestions.
(It looks odd to have highlighting in some suggestions but not others,
with no apparent difference to the user.)
|
|
Fix incorrect property name from 764d70312f292882abe4940adf9fee3d6e834327.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Use a rightwards hooked arrow instead of a small greater-than sign,
which according to @philc, renders as a large greater-than sign on Macs,
See #1651.
|
|
|
|
|
|
|
|
Conflicts:
background_scripts/completion.coffee
|
|
|
|
|
|
See example in diff.
Do not offer a suggestion if it is what the user would get anyway if
they just hit <Enter>.
|
|
This reverts commit 4309dcd3030687f3ed02b86bbdf7c485baaee4a5.
This is a bad idea. It pushes the suggestion at the top of the list out
of the way. Users aren't going to like that if it's the one they're
looking for.
Conflicts:
background_scripts/completion.coffee
|
|
|
|
|
|
This address "UX Issue 2" from #1651.
If the user types "w lake vict" and sees a suggestion "lake victoria
perch", and continues "w lake vict pe", then we retain the previous
suggestion (which still matches) despite the fact that the completion no
longer delivers it.
This creates a more consistent, Vimium-like vomnibar UX.
|
|
|
|
Conflicts:
background_scripts/completion.coffee
|
|
|
|
This puts the first (top) completion suggestion at the top of the list:
either one or two <Tab>s away, depending upon whether a domain-completer
suggestion is present or not.
|
|
The relevancy score of completion suggestions should not change as the
user continues to type. See "UX Issue 1" in #1651.
(The effect of the previous implementation was that search completions
would jump, unpredictably, up the suggestion list, often displacing
suggestions from other completers for no reason which was apparent to
the user.)
|
|
Oops. I left this on, again.
|
|
|
