| Age | Commit message (Collapse) | Author |
|---|
|
Add header for Advanced Options.
|
|
Approach: Re-use the existing AsynDataFetcher class to "fetch" and use
the iframe message port. Messages are queued until the iframe's
contents have loaded and the message port is open.
Fixes #1679.
|
|
|
|
Only replace double-slashes in find mode if they precede our flags
|
|
Fixes #544.
Copy of #655.
|
|
|
|
This ensures that \\\r is interpreted as {escaped-\}{escaped-r} rather
than \{escaped-\}r.
|
|
This fixes #1673
|
|
|
|
|
|
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
|
|
See #1671.
The problem was that we were making the vomnibar visible in the frontend,
even if the vomnibar initialisation was not yet complete, and the iframe
port was not yet available.
(Also, @activate() is never being called without options, so we can drop
that test.)
Fixes #1671.
|
|
smblott-github/retain-previous-matching-suggestions
Retain previous matching completion suggestions.
|
|
|
|
|
|
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.
|
|
|
|
|
|
This ensures that URLs which differ only in their case are considered
duplicates, hence one is dropped.
|
|
A custom search engine like this...
i: https://www.google.ie/search?q=%s&num=30&newwindow=1&biw=1918&bih=1015&tbm=isch Google image search
Should not match a URL like this...
https://www.google.ie/search?q=bbc+sport
|
|
|
|
|
|
|
|
|
|
|
|
When the user begins editing the inserted text from a
custom-search-engine suggestion, we reactivate the original
custom-search-engine mode.
|
|
Note: There's still an unpleasant flicker when this happens.
TBD: Fix this.
|
|
|
|
|
|
|
|
`o` then `Tab` opens the vomnibar completionlist with history
completions (the only completions) ranked by recently only. Hence, the
most recent requests are at the top.
This is a (far) simpler approach than #1662 which catches the most
important use case (repeat a search with an edited query).
|
|
If the URL contains a query term such as vierwaldstättersee, then we
render the URL encoded version in the vomnibar. It looks considerably
nicer to render URL-decoded version.
|
|
smblott-github/search-completion-with-regular-relevancy
Search completion with regular relevancy calculation
|
|
|
|
If we go with this and #1662, then we can share the utility.
|
|
|
|
See the comment in the diff.
This test was in a previous version, but was dropped because with
eb0e2964fca5ef2eccc06607944df6b208b2b99f, it was (thought to be) no
longer possible to filter by relevancy score since we don't know what
the relevancy score will be.
The filter is reinstated here because we use the simple idea that,
whatever relevancy scores are assigned to completion suggestions, they
will be less than the score for a perfect suggestion.
|
|
This is an alternative relevancy-scoring scheme for search completion.
It attempts to address the "clumping" effect described in #1651 by:
- Using the regular relevancy scoring scheme (but based only on the
title (so, not the URL).
- Weighting relevancy scores (exponentially) by the length the query
(so, search suggestions score higher as the length of the query gets
longer).
- Weighting suggestions (fairly moderately) by their position in the
suggestion list as returned by the completion engine. We generally
want to retain this ordering.
- Applying a calibration fudge factor to roughly calibrate (boost)
search-completion suggestions with those from other search engines.
|
|
|
|
|
