Sorry, forgot to mention: what I typed in the ombibox was "test testApi" (without quotes)

And here's the output when typing just "test". I attach this because (as described in the original report) when I was observing the issue (i.e., omnibox output for "test testApi" did not include the expected url from history http://xxxxx.wiki/test/testApi), the url did show up as expected when typing just "test". So again, even if this is not the output that reproduced the issue, hopefully it can provide some insight.

cursor position = 4
elapsed time = 126ms
all providers done = true
host = test has is_typed_host = false
Combined results.
Provider	Type	Relevance	Contents	Can Be Default	Starred	Description	URL	Fill Into Edit	Inline Autocompletion	Del	Prev	Tran	Done	Associated Keyword	Keyword	Duplicates	Additional Info
Search	search-what-you-typed	1300	test	✔	✗	Google Search	https://www.google.es/search?q=test&oq=test&aqs=chrome..69i57j69i60l3j69i65j69i60&sourceid=chrome&ie=UTF-8	test		✗	✗	5	✔		google.es	0	
relevance_from_server:	true
should_prefetch:	false
HistoryQuick	history-url	1399	https://xxxxx.wiki/test/testApi	✗	✗	XxxxxWiki, Yyyyyyyyy yyy Yyyyyy	https://xxxxx.wiki/test/testApi	https://xxxxx.wiki/test/testApi		✔	✗	1	✔			1	
last visit:	2/5/17, 10:06:26 PM
typed count:	18
visit count:	48
HistoryQuick	history-url	1398	https://fake.xxxxx.wiki/test/testApi	✗	✗	XxxxxWiki, Yyyyyyyyy yyy Yyyyyy	https://fake.xxxxx.wiki/test/testApi	https://fake.xxxxx.wiki/test/testApi		✔	✗	1	✔			0	
last visit:	1/28/17, 10:03:00 PM
typed count:	8
visit count:	19
HistoryQuick	history-url	1397	fake.xxxxx.wiki/test/test	✗	✗	CException	http://fake.xxxxx.wiki/test/test	fake.xxxxx.wiki/test/test		✔	✗	1	✔			0	
last visit:	2/5/17, 9:04:45 PM
typed count:	6
visit count:	8
Bookmark	bookmark-title	904	www.newrepublic.com/article/119321/harvard-ivy-league-should-judge-students-standardized-tests	✗	✔	Harvard, Ivy League Should Judge Students by Standardized Tests | New Republic	http://www.newrepublic.com/article/119321/harvard-ivy-league-should-judge-students-standardized-tests	www.newrepublic.com/article/119321/harvard-ivy-league-should-judge-students-standardized-tests		✗	✗	1	✔			0	
HistoryURL	history-url	900	https://test.xxxxx.wiki	✔	✗		https://test.xxxxx.wiki/	https://test.xxxxx.wiki	.xxxxx.wiki	✗	✗	1	✔			0	
last visit:	1/1/70, 1:00:00 AM
typed count:	0
visit count:	0

Tested in chrome # 56.0.2924.87 and Canary #58.0.3010.0 on Ubuntu 14.04 and not able to reproduce the issue.Search results are displaying as expected.Please find the screen shots for your reference.

@teo8976: As per your comments issue is not reproducible in latest builds so could you please conform once can we close the issue.Which would help us to triage the issue further.

Thanks in Advance.

Deleted: 691217.png 251 KB

	691217.png 251 KB View Download

>  As per your comments issue is not reproducible in latest builds so could 
> you please conform once can we close the issue

What? You haven't read my fucking report, have you.

The reason why I can't reproduce it any more is, most probably, that I have visited the url many more times causing it to score higher. Not because the issue is fixed.

Looking at that data, it's consistent with your report that we're now seeing these as frequently visited + typed and scoring them highly as a result.  Unfortunately that leaves little explanation for what was going wrong before.  The need for data while the issue is reproducing is because after-the-fact it's not really possible to discern what happened :/.

I'm going to close because we still can't take action here, but leave this one unlocked (at least for now) so that if you see something like this again you can easily alert us.

Isn't it likely that the url was scoring lower because it had been visited less frequently recently (e.g. less times in the last X days/months)?

Isn't that something you can easily emulate and try? (as opposed to me, who would have to actually wait without visiting the url)

Is there a scenario, depending on how often and how long ago the url has been visited, where the url could score lower than "search what you type" and/or suggested searches? If there is, then you already have something wrong without a need to reproduce the issue: an url that is in the history, with such a strong match (two entire words!), should never, ever be outscored by search suggestions (especially those obtained by arbitrarily manipulating the keywords and adding more keywords).

I also notice that the score of the url when typing "test testApi" is the same as when typing just "test". Isn't that alone wrong? Shouldn't it score higher and higher as I type more characters and words that match? The paradox in the original report is that I get the expected result when typing just "test" and then I "loose" it when typing "test testApi" (and I've seen a lot of examples of this, where a result from history shows up while typing and goes away when typing more stuff that actually matches the url)


I'm starting to wonder if this is a case of 369989

By the way I linked the wrong issue in the first post. It's 584974

There are many scenarios where URLs can score lower than search suggestions.  For example, a URL visited once a month ago matching three arbitrary characters of your input would score lower than many search suggestions.  These sort of details are why data at the time the bug is reproducing is important -- we have to check the exact character strings in the whole URL plus the typed and visit counts and visit dates to know what we should expect and how, if something is wrong, we could tune the heuristics to improve.  Generally the problem is that boosting a lot of history scores winds up surfacing irrelevant URLs for every set of character inputs until you type so many characters it can't possibly match anything anymore, which is a negative experience.

As for test vs. testApi, there's a maximum score for various different situations, so scores aren't expected to continually rise.  Regarding how scores change as you type more, it depends on precisely how the URL is broken into tokens and parsed against the input.  For example, if you have a URL like "foo.com/bar" and you type "foo ar", the "ar" will probably disqualify the URL since, while it is a substring match, it doesn't start at the start of a token, and those are much lower quality matches.  (mpearson can correct me if I got the tokenizer details wrong there.)

It's quite possible  bug 369989  covers this.