I think if the cursor is mid-word we pretend there's a word break there.  Maybe we should try to match both with and without the word break.

Or, if we did mid-word matching (see  bug 592006 ), maybe this would just work?

Interesting.  Thanks for filing this.

>>>
I think if the cursor is mid-word we pretend there's a word break there.  Maybe we should try to match both with and without the word break.
>>>
I agree with your diagnosis.  The solution--retrieving both sets--sounds right too.  I'm not sure about how the scoring should work: should we score all the URLs from the two retrieval passes against longer input (which pretends there is a space where the cursor is) or the shorter one or have each URL scored against whichever input returned it?  I think the last option is probably the best.  This will mean we're comparing URLs scored against an input of n words with URLs scored against an input of n+1 words.  This isn't theoretically right but it probably will just work fine.

I'm not going to have any time to work on this.  I'm happy to review patches.

I'm tagging this as good first bug because I believe the change will be entirely localized to a single function:
https://code.google.com/p/chromium/codesearch#chromium/src/components/omnibox/browser/url_index_private_data.cc&sq=package:chromium&l=155&rcl=1457095095

>>>
I think if the cursor is mid-word we pretend there's a word break there.  Maybe we should try to match both with and without the word break.
>>>

Nope. If that was the case (which would be totally ridiculous), moving the cursor within a word would make results disappear, or more rarely appear (if you happen to move to a position where splitting the word that doesn't match results in two words that match). And that is not the case: moving the cursor does nothing.

> The solution--retrieving both sets--sounds right too

If you did that, moving the cursor throughout the text would cause results to randomly change from time to time. 



To me it seems more like the issue is that when a whitespace is deleted, the results are not updated.

Actually, results are often not updated, in random cases, when deleting and adding characters (whether they are spaces or not) in the middle of the input string (be it on the boundary of a word or in the middle of it).

I can't find a pattern in the behavior, but deleting or adding characters anywhere else than at the end of the string, sometimes results are not updated (even if they should change which can be tested by moving to the end of the input and adding a space).

> If that was the case (which would be totally ridiculous), moving the cursor within a word would make results disappear ... that is not the case: moving the cursor does nothing.

Moving the cursor only does nothing because it doesn't re-run autocomplete.  If something else runs autocomplete, as happens when you delete the space, the presence of the cursor causes us to treat it as a word break.

>> The solution--retrieving both sets--sounds right too
>
> If you did that, moving the cursor throughout the text would cause results to randomly change from time to time.

No, because moving the cursor does not rerun autocomplete.

> deleting or adding characters anywhere else than at the end of the string, sometimes results are not updated (even if they should change which can be tested by moving to the end of the input and adding a space).

Adding a space at the end of the input is, I believe, guaranteed not to change the results based on how our algorithms work.

All character additions and deletions rerun autocomplete.  The new results may not differ from the old, however, depending on precisely what change you made.

The underlying system here is complex.  I advise you not to try to mentally reverse-engineer it, only because doing so accurately is extremely hard :).  Describing the problem you're having, as you did quite well in comment 0, should hopefully be sufficient for us to trace this down.

Oh, yes, I see how adding the word break at the position of the cursor probably explains the issue.

And thinking about it, I think I also see why that behavior perhaps was conceived, even though it turns out to be a bad idea as the issue demonstrates.

However, note that the proposed solution is still wrong.

Supposed I write:
  fooxbar
which matches nothing.
Then I edit it, deleting the x.
Now the cursor is between "foo" and "bar", so, according to your proposed solution, you would retrieve both results for "foo bar" and for "foobar". Let's say there are matches for "foo bar" only.
Now I hit the "end" key, so the cursor goes to the end, which does NOT rerun autocomplete.
So now I am looking at the word "foobar" and I have results that match "foo bar", unrelated to the input. Had I simply typed "foobar" I wouldn't be seeing those matches.

In this particular example you may argue that I am only getting more results than I should, not less, so what's the problem (besides the annoyance of seeing confusing unrelated results), but in a more elaborate scenario where the spurious results compete with the expected ones, one may actually loose relevant results in favour of random ones.

You're not actually arguing that the proposed solution is wrong.  You're really arguing that hitting the end key should rerun autocomplete (which will drop the "separate words" interpretation).  Before you hit "end", we truly don't know what you intend here, so it's not wrong to look for both interpretations.  Hitting "end" is what makes it clear you only want one and not the other.

However, I'm not willing to change the current behavior that moving the cursor does not rerun autocomplete.  The downsides are much larger and more common than the upsides, even if it is true that in the case you describe, you may get some matches that aren't as relevant to you.

> You're not actually arguing that the proposed solution is wrong.  
> You're really arguing that hitting the end key should rerun autocomplete

Was that part of the proposed solution? ;P


Note that hitting end is only a particular case. What if I hit the home key instead? What if I just move the cursor a few characters away? The results still become unrelated to the current input.


> However, I'm not willing to change the current behavior that moving the cursor does not 
> rerun autocomplete.  The downsides are much larger and more common than the upsides

If you blindly rerun autocomplete at every movement of the cursor, of course.
(by the way, when you invented the "add a fake word break at the position of the cursor" behavior, I wish you had seen that the downsides were a lot larger than the upsides, too)

However, I'm afraid there's no real solution as long as you intend to keep the fake word break (even if its results are added to those without it). If you were to rerun autocomplete when the cursor has moved and a timeout has passed, for example, there would still be the downside that one may see an interesting result appear and then disappear.

By adding the word break at the cursor, you introduced an inconsistency (in that the same input won't always produce the same output) and that can only be "compensated" by introducing more inconsistencies.

I'd rather have something that gives reproducible results than a supersmart machine that sometimes anticipates my wishes ahead of time but other times can't be relied upon.

Why do you add the word break at cursor position in the first place? I guess it is with this use case in mind. I'm thinking of a movie, it was "mind <something>" So I type "mind". Then I remember, it was "beautiful mind", not "mind something", so I move to the beginning and start typing "beau"...  (without a space between the first word I'm typing now and the second I had already typed). Thanks to the magical break-word-on-cursor algorithm, I don't have to type the full word "beautiful" plus a space: as soon as I have typed a few letters I already have a match for "beau[tiful] mind". 
Cool, but is that single use case really worth opening the pandora box of total unpredictability? We have seen the current behavior is an unacceptable mess, now ok, retrieving two sets of results will be an improvement, but it is still subject to a huge amount of inconsistencies.

Now just to name a simple example: If I put the cursor right after the space in "foo bar" and DELETE THAT SPACE, shouldn't I legitimally expect the results for the two separate words to disappear? They won't with the both-result-sets rule. Will you treat this as yet another special case to be corrected?

Also, if one places the cursor in the middle of a word (as opposed to at the beginning of the textbox) and starts deleting characters (or even adding them, without adding spaces), she is much more likely editing a misspelled word than typing an additional one - I mean, assuming a word break there almost certainly doesn't make sense.



> even if it is true that in the case you describe, you may get some matches that 
> aren't as relevant to you.

you forget the part where you may also loose relevant, even obvious results (if they get overscored by the irrelevant ones)

I'd like to fix this as a first bug.  I am just not sure there is a consensus around how the solution should be implemented.  It seems that the corner cases are what's causing the problem.  For instance, for the case where the space between foo and bar in "foo bar" gets deleted can't we just detect that the user has deleted a space and not insert a fake word break?

We can do the same when a user starts deleting or adding characters in the middle of a word.  If we look at the previous version of the word and detect that it has been changed without adding a new term we can assume that a fake word break is not needed.

I think we just need to list the scenarios here and address then one by one.

I don't think we can assume that deleting a space means we shouldn't insert a word break, especially if when the user starts typing again we go back to inserting one, and even more if just arrowing around goes back to inserting a break.  That will feel very inconsistent.

I think the idea of simply fetching both the with-break and without-break results is safer.

Okay.  I will take this on as a good first bug.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e3235816f23e9eb733d11bdecdfd5f8ca67cec9f

commit e3235816f23e9eb733d11bdecdfd5f8ca67cec9f
Author: open.hyperion <open.hyperion@gmail.com>
Date: Mon Sep 12 21:40:32 2016

Generating autocomplete results with and without word breaks in the Omnibox.

The goal is to support mid-word autocomplete in the Omnibox.  Currently, if the user types "funtimes", inserts the cursor between the "n" and the "t" and begins typing the word "good" the Ominbox will search for URL results that match "fungood times" only.  We want to also search for "fungoodtimes".

BUG= 591979 
TEST=0. Clear browser history.
1. Visit the following link: https://twitter.com/fungoodtimes
2. Open a new browser tab.
3.Type into the Omnibox "funtimes".  Note the lack of the suggestion for the above URL.
4. Insert the cursor between the "n" and "t" in "funtime" and type "good".
5. The above URL should show in the autocomplete list.

Review-Url: https://codereview.chromium.org/2187343002
Cr-Commit-Position: refs/heads/master@{#418054}

[modify] https://crrev.com/e3235816f23e9eb733d11bdecdfd5f8ca67cec9f/AUTHORS
[modify] https://crrev.com/e3235816f23e9eb733d11bdecdfd5f8ca67cec9f/components/omnibox/browser/history_quick_provider_unittest.cc
[modify] https://crrev.com/e3235816f23e9eb733d11bdecdfd5f8ca67cec9f/components/omnibox/browser/url_index_private_data.cc
[modify] https://crrev.com/e3235816f23e9eb733d11bdecdfd5f8ca67cec9f/components/omnibox/browser/url_index_private_data.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1a30ef7b27c9c4b3d0df1ff7eb93cb3d506d35b1

commit 1a30ef7b27c9c4b3d0df1ff7eb93cb3d506d35b1
Author: mpearson <mpearson@chromium.org>
Date: Fri Sep 23 01:04:37 2016

Revert of Generating autocomplete results with and without word breaks in the Omnibox. (patchset #13 id:240001 of https://codereview.chromium.org/2187343002/ )

Reason for revert:
Reverting.  Will be replaced by cleaner implementation:
https://codereview.chromium.org/2363463002/

--mark

Original issue's description:
> Generating autocomplete results with and without word breaks in the Omnibox.
>
> The goal is to support mid-word autocomplete in the Omnibox.  Currently, if the user types "funtimes", inserts the cursor between the "n" and the "t" and begins typing the word "good" the Ominbox will search for URL results that match "fungood times" only.  We want to also search for "fungoodtimes".
>
> BUG= 591979 
> TEST=0. Clear browser history.
> 1. Visit the following link: https://twitter.com/fungoodtimes
> 2. Open a new browser tab.
> 3.Type into the Omnibox "funtimes".  Note the lack of the suggestion for the above URL.
> 4. Insert the cursor between the "n" and "t" in "funtime" and type "good".
> 5. The above URL should show in the autocomplete list.
>
> Committed: https://crrev.com/e3235816f23e9eb733d11bdecdfd5f8ca67cec9f
> Cr-Commit-Position: refs/heads/master@{#418054}

TBR=open.hyperion@gmail.com
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG= 591979 

Review-Url: https://codereview.chromium.org/2364523003
Cr-Commit-Position: refs/heads/master@{#420521}

[modify] https://crrev.com/1a30ef7b27c9c4b3d0df1ff7eb93cb3d506d35b1/AUTHORS
[modify] https://crrev.com/1a30ef7b27c9c4b3d0df1ff7eb93cb3d506d35b1/components/omnibox/browser/history_quick_provider_unittest.cc
[modify] https://crrev.com/1a30ef7b27c9c4b3d0df1ff7eb93cb3d506d35b1/components/omnibox/browser/url_index_private_data.cc
[modify] https://crrev.com/1a30ef7b27c9c4b3d0df1ff7eb93cb3d506d35b1/components/omnibox/browser/url_index_private_data.h

The better implementation of the fix has been submitted here:
https://chromium.googlesource.com/chromium/src/+/eccdb2b8454318889abf958d86fbf668e2908cc6

Thanks open.hyperion for the fix!

I think this is good enough for this bug.  (There are some other cases to be considered such as pressing home/end or the act of deleting a space should prevent searching for matches where the cursor is.  I'm not sure these discussions are worth the time to have given how narrow the scope is.)