1466697 - Keyword parsing problems with restriction sigils and leading space

Status: NEW

(Firefox :: Address Bar, defect, P5)

Description

[Peter Simonyi]

Steps to reproduce:

1. Install an extension that registers a keyword with the 'omnibox' API.
For testing I've been using this: https://addons.mozilla.org/en-US/firefox/addon/subredditsearch/
Its keyword is "sub".

2. Set a bookmark keyword.  For example, I've been using "sf" for searchfox.org.

3. Set a keyword (alias) for a search engine.  In this example, I'll use "ddg" for DuckDuckGo.

4. Type in the location bar:

a) " sub" (note leading whitespace)
Expected: Suggestions matching "sub"; no extension results because there's no space after the extension's keyword.
Actual: The extension's "heuristic result" is present (though I think this does not causes extension code to run) and the error console complains that the search doesn't start with "sub ".  Choosing this heuristic result doesn't do anything.  The other suggestions are as expected.

b) " sub something" (again, leading whitespace)
Expected: Extension's suggestions for "something" plus regular bookmarks/history/search suggestions for "sub something"; the same as if "sub something" had been typed.
Actual: The extension's heuristic result from a) is still present but no other extension results are shown.  The same errors are in the console.  The regular suggestions are the same as for " sub"; they stop updating for the subsequent terms.

c) "* sub something"
Expected: Bookmarks matching "sub something" only; no extension results.
Actual: The same errors and heuristic result as a) and b), and no bookmarks.

d) "* sf something"
Expected: Bookmarks matching "sf something" only; no searchfox search.
Actual: Bookmark results as expected, but the heuristic (first) result is a Places keyword search on searchfox.org, and the query term is "f something" -- note the missing "s".  With two spaces between "*" and "sf", the query term is "sf something".  In general adding more characters (spaces or extra sigils like %) before the keyword lets more of the keyword into the query.

e) "* ddg something"
This is the same as d) only with a search engine alias instead of a Places keyword.

Comment 1

[Peter Simonyi]

I'm working on this.

Comment 2

[Marco Bonardo [:mak]]

(In reply to Peter Simonyi from comment #0)
> c) "* sub something"
> Expected: Bookmarks matching "sub something" only; no extension results.
> Actual: The same errors and heuristic result as a) and b), and no bookmarks.

The extension is not necessarily returning things in the bookmarks/history/whatever space, it can actually return anything it wants, and as such it may not be possible to limit results to bookmarks.
The problem may be similar in other cases, where it's unclear if an entry is a bookmark or not.
Probably using an "*" or another restriction char in these specific cases is just wrong (and should be ignored)

Comment 3

[Peter Simonyi]

(In reply to Marco Bonardo [::mak] from comment #2)
> (In reply to Peter Simonyi from comment #0)
> > c) "* sub something"
> > Expected: Bookmarks matching "sub something" only; no extension results.
> > Actual: The same errors and heuristic result as a) and b), and no bookmarks.
> 
> The extension is not necessarily returning things in the
> bookmarks/history/whatever space, it can actually return anything it wants,
> and as such it may not be possible to limit results to bookmarks.
> The problem may be similar in other cases, where it's unclear if an entry is
> a bookmark or not.
> Probably using an "*" or another restriction char in these specific cases is
> just wrong (and should be ignored)

In this case, with a leading sigil followed by a word, I meant that the word should not be treated as a keyword at all, so "* sub something" is the same as "* something sub"; it's just a plain search for bookmarks and the extension isn't returning any results.  I'm suggesting that keyword should only be effective as keywords (Places, extension, or search alias) if they're the first non-whitespace thing.

It seems like "sub something *" is the weird case you're talking about?  In this case, I agree it doesn't make much sense for us to treat the * as a restriction character, though it should still be passed along to whatever extension or URL or whatever handles the keyword.

Comment 4

[Marco Bonardo [:mak]]

(In reply to Peter Simonyi from comment #3)
> In this case, with a leading sigil followed by a word, I meant that the word
> should not be treated as a keyword at all, so "* sub something" is the same
> as "* something sub"; it's just a plain search for bookmarks and the
> extension isn't returning any results.  I'm suggesting that keyword should
> only be effective as keywords (Places, extension, or search alias) if
> they're the first non-whitespace thing.

That could make sense, yes.

Comment 5

[Marco Bonardo [:mak]]

(In reply to Peter Simonyi from comment #0)

a) " sub" (note leading whitespace)

This works for me, until you type a space after sub, we don't consider it a magic word.
If I type a space after the word, the experience is not optimal since the heuristic does nothing.

b) " sub something" (again, leading whitespace)

it looks correct but it's broken when picked.

c) "* sub something"
d) "* sf something"
e) "* ddg something"

These should now be fixed.