If you remove the custom search engine does the issue stop occurring?

Yes, I removed the custom search engine, and the issue went away.

Can you supply the details of the custom search engine you added?  Basically, I'm looking for an exact set of steps to try locally on a clean profile to see if I can reproduce this.

Okay.  It was under "other search engines", and I named it Assembla, keyword was "t", and the url with %s was "https://platphorm.assembla.com/spaces/phrendly/tickets/%s".

Sadly, that's not something you are going to be able to access.  Hope that doesn't interfere with testing.  Thanks for taking a look at this.

I added it back, and it's happening again.  Yay for it not being a heisenbug.  Here's some additional repro detail.  

I have this URL in my history:
https://platphorm.assembla.com/spaces/phrendly/tickets/realtime_cardwall?tickets_report_id=u2063603

And that works, loads correctly.

But if I paste that url, and then hit delete a few times to trim off the last few characters, then it becomes a google search.  I've now edited it down to 
https://platphorm.assembla.com/spaces/phrendly/tickets/realtime_cardwall?tickets_report_id=u206
  

BUT if I then add any characters, like z, it becomes a URL nav again.  Like
https://platphorm.assembla.com/spaces/phrendly/tickets/realtime_cardwall?tickets_report_id=u206z

The bug appears to require that you've just taken an action to trim off the end of a url.  (In retrospect, I realize this was true of my initial report as well).

Changing based on when you delete versus re-add characters is probably due to the "prevent inline autocomplete" flag getting flipped when you hit backspace (and cleared when you type).

You can try using about:omnibox to enter some test URLs.  Toggle the "prevent inline autocomplete" checkbox on and off to see what happens.

If you find cases that look interesting, check the "Show all details" box and paste the output here (don't worry about reformatting, I can read the spew).

You guys have crazy quick feedback on your bug reports.  Kudos.

Here's the results for "https://platphorm.assembla.com/spaces/phrendly/tickets/realtime_cardwall?tickets_report_id=u20" with the checkbox empty.   I'm not 100% sure what all this about:omnibox page can do, but toggling that checkbox causes an immediate swap back and forth between the first and second results (and no other effects).  

Provider	Type	Relevance	Contents	URL
HistoryURL	history-url	1413	https://platphorm.assembla.com/spaces/phrendly/tickets/realtime_cardwall?tickets_report_id=u2063603	https://platphorm.assembla.com/spaces/phrendly/tickets/realtime_cardwall?tickets_report_id=u2063603
Search	search-what-you-typed	850	https://platphorm.assembla.com/spaces/phrendly/tickets/realtime_cardwall?tickets_report_id=u20	https://www.google.com/search?q=https%3A%2F%2Fplatphorm.assembla.com%2Fspaces%2Fphrendly%2Ftickets%2Frealtime_cardwall%3Ftickets_report_id%3Du20&oq=https%3A%2F%2Fplatphorm.assembla.com%2Fspaces%2Fphrendly%2Ftickets%2Frealtime_cardwall%3Ftickets_report_id%3Du20&aqs=chrome..69i60j69i57j69i59&sourceid=chrome&ie=UTF-8
Search	search-history	639	https://platphorm.assembla.com/spaces/phrendly/tickets/realtime_cardwall?tickets_report_id=u2063603	https://www.google.com/search?q=https%3A%2F%2Fplatphorm.assembla.com%2Fspaces%2Fphrendly%2Ftickets%2Frealtime_cardwall%3Ftickets_report_id%3Du2063603&oq=https%3A%2F%2Fplatphorm.assembla.com%2Fspaces%2Fphrendly%2Ftickets%2Frealtime_cardwall%3Ftickets_report_id%3Du20&aqs=chrome.2.69i60j69i57j69i59&sourceid=chrome&ie=UTF-8

Is it interesting that if I put in the url "https://asdfasdfd.com"  (garbage typing), I get a "HistoryURL	url-what-you-typed", but if I try with my partially-deleted link to the cardwall, I get "HistoryURL	history-url" and "Search  search-what-you-typed"?

Oh, sorry, you said show all details.   Here's the spew for https://platphorm.assembla.com/spaces/phrendly/tickets/realtime_cardwall?tickets_report_id=u20 , with the autocomplete checkbox empty


cursor position = 94
elapsed time = 5ms
all providers done = true
host = platphorm.assembla.com has is_typed_host = true
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
HistoryURL	history-url	1413	https://platphorm.assembla.com/spaces/phrendly/tickets/realtime_cardwall?tickets_report_id=u2063603	✔	✔	Cardwall | phrendly Project | Assembla	https://platphorm.assembla.com/spaces/phrendly/tickets/realtime_cardwall?tickets_report_id=u2063603	https://platphorm.assembla.com/spaces/phrendly/tickets/realtime_cardwall?tickets_report_id=u2063603	63603	✔	✗	1	✔			1	
last visit:	9/19/16, 2:16:45 PM
typed count:	2
visit count:	15
Search	search-what-you-typed	850	https://platphorm.assembla.com/spaces/phrendly/tickets/realtime_cardwall?tickets_report_id=u20	✔	✗	Google Search	https://www.google.com/search?q=https%3A%2F%2Fplatphorm.assembla.com%2Fspaces%2Fphrendly%2Ftickets%2Frealtime_cardwall%3Ftickets_report_id%3Du20&oq=https%3A%2F%2Fplatphorm.assembla.com%2Fspaces%2Fphrendly%2Ftickets%2Frealtime_cardwall%3Ftickets_report_id%3Du20&aqs=chrome..69i60j69i57j69i59&sourceid=chrome&ie=UTF-8	https://platphorm.assembla.com/spaces/phrendly/tickets/realtime_cardwall?tickets_report_id=u20		✗	✗	5	✔		google.com	0	
relevance_from_server:	false
should_prefetch:	false
Search	search-history	638	https://platphorm.assembla.com/spaces/phrendly/tickets/realtime_cardwall?tickets_report_id=u2063603	✔	✗		https://www.google.com/search?q=https%3A%2F%2Fplatphorm.assembla.com%2Fspaces%2Fphrendly%2Ftickets%2Frealtime_cardwall%3Ftickets_report_id%3Du2063603&oq=https%3A%2F%2Fplatphorm.assembla.com%2Fspaces%2Fphrendly%2Ftickets%2Frealtime_cardwall%3Ftickets_report_id%3Du20&aqs=chrome.2.69i60j69i57j69i59&sourceid=chrome&ie=UTF-8	https://platphorm.assembla.com/spaces/phrendly/tickets/realtime_cardwall?tickets_report_id=u2063603	63603	✔	✗	5	✔		google.com	0	
relevance_from_server:	false
should_prefetch:	false

And here's the spew with the checkbox checked:


cursor position = 94
elapsed time = 5ms
all providers done = true
host = platphorm.assembla.com has is_typed_host = true
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	850	https://platphorm.assembla.com/spaces/phrendly/tickets/realtime_cardwall?tickets_report_id=u20	✔	✗	Google Search	https://www.google.com/search?q=https%3A%2F%2Fplatphorm.assembla.com%2Fspaces%2Fphrendly%2Ftickets%2Frealtime_cardwall%3Ftickets_report_id%3Du20&oq=https%3A%2F%2Fplatphorm.assembla.com%2Fspaces%2Fphrendly%2Ftickets%2Frealtime_cardwall%3Ftickets_report_id%3Du20&aqs=chrome..69i57j69i60j69i59&sourceid=chrome&ie=UTF-8	https://platphorm.assembla.com/spaces/phrendly/tickets/realtime_cardwall?tickets_report_id=u20		✗	✗	5	✔		google.com	0	
relevance_from_server:	false
should_prefetch:	false
HistoryURL	history-url	1413	https://platphorm.assembla.com/spaces/phrendly/tickets/realtime_cardwall?tickets_report_id=u2063603	✗	✔	Cardwall | phrendly Project | Assembla	https://platphorm.assembla.com/spaces/phrendly/tickets/realtime_cardwall?tickets_report_id=u2063603	https://platphorm.assembla.com/spaces/phrendly/tickets/realtime_cardwall?tickets_report_id=u2063603		✔	✗	1	✔			2	
last visit:	9/19/16, 2:16:45 PM
typed count:	2
visit count:	15
Search	search-history	638	https://platphorm.assembla.com/spaces/phrendly/tickets/realtime_cardwall?tickets_report_id=u2063603	✗	✗	Google Search	https://www.google.com/search?q=https%3A%2F%2Fplatphorm.assembla.com%2Fspaces%2Fphrendly%2Ftickets%2Frealtime_cardwall%3Ftickets_report_id%3Du2063603&oq=https%3A%2F%2Fplatphorm.assembla.com%2Fspaces%2Fphrendly%2Ftickets%2Frealtime_cardwall%3Ftickets_report_id%3Du20&aqs=chrome.2.69i57j69i60j69i59&sourceid=chrome&ie=UTF-8	https://platphorm.assembla.com/spaces/phrendly/tickets/realtime_cardwall?tickets_report_id=u2063603		✔	✗	5	✔		google.com	0	
relevance_from_server:	false
should_prefetch:	false

The absence of a "url-what-you-typed" result is the problem.  Why it's absent I don't know.

What your data says is that, when you haven't just hit backspace, you're getting inline-autocompleted to the full "u2063603" URL, which is why it navigates if you hit enter in that case.  When you have, there is no "what you typed" result to fall back on, so we believe navigation is impossible.

Can you try the same input, with "prevent inline autocomplete" and "show all details" checked, but also "show results per provider, not just merged results"?  Then just show me the results for the HistoryURL provider table.

My suspicion is that we're getting the right thing from this provider, but it's being duped incorrectly against the Search result.

Your suspicion looks correct.  Here's the table you asked for, from the same url as above.

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
HistoryURL	history-url	1413	https://platphorm.assembla.com/spaces/phrendly/tickets/realtime_cardwall?tickets_report_id=u2063603	✗	✔	Cardwall | phrendly Project | Assembla	https://platphorm.assembla.com/spaces/phrendly/tickets/realtime_cardwall?tickets_report_id=u2063603	https://platphorm.assembla.com/spaces/phrendly/tickets/realtime_cardwall?tickets_report_id=u2063603		✔	✗	1	✔			0	
last visit:	9/19/16, 2:16:45 PM
typed count:	2
visit count:	15
HistoryURL	url-what-you-typed	1203	https://platphorm.assembla.com/spaces/phrendly/tickets/realtime_cardwall?tickets_report_id=u206	✔	✗		https://platphorm.assembla.com/spaces/phrendly/tickets/realtime_cardwall?tickets_report_id=u206	https://platphorm.assembla.com/spaces/phrendly/tickets/realtime_cardwall?tickets_report_id=u206		✗	✗	1	✔			0	

And yes, the url-what-you-typed disappears once we merge provider results.

OK, I think I know what's going on.

As part of de-duping, the omnibox code computes a "stripped destination URL" for all matches.  Among other things, this looks to see whether the match's destination could have plausibly come from a search engine (built in or custom).  If so, the "stripped destination" removes all substitutions other than the search terms.  This is then compared to other matches' stripped destinations for deduping purposes.  The goal here is that we not show multiple matches in the drop down that are e.g. searches for the same string but with slightly different CGI params and such.  

I think the history-url and history-what-you-typed matches are both getting matched against your custom search engine, which computes their stripped destination URLs as the same.  So they're dupe-eliminated against each other, and the history-url one (for inline autocompletion) scores higher and thus wins.

When typing normally, this isn't so bad, because you just don't see a dropdown entry for the "what you typed" match as a navigation.  But when prevent_inline_autocomplete is on, this match is (correctly) marked as not-allowed-to-be-default, leading to the default behavior being to search.  I bet in a debug build, you'd hit a DCHECK, because the default action for a URL input was to search.

This is slightly related to bug 542780 (about handling duping across matches with differing values of "can be default").  CCing Mark.

I'm not precisely sure how to fix this.  Need to think more about what step in the above chain is wrong.

This is also similar to  bug 512203 , which is another case of a user trying to modify a URL that's associated with a search provider and having trouble.

I think the fundamental idea of stripping the other params out and deduping based on that is sound, so the fix isn't to remove that.

The fix isn't to just copy "can be default" from the duped-away match onto the duped-against match.  That would result in undeletable autocompletion in this case.

I think the fix isn't that we block matches of different types (history-url vs. history-what-you-typed) from being duped against each other, because we _want_ to dupe e.g. past searches for the same thing against your current typing.

One fix I don't really like would be to say that, when duping the WYT match and another thing, the WYT match should always win, regardless of relevance.  That might break the inline autocompletion when not backspacing in this case, depending on whether the HUP is providing a WYT match then.

A fix with a similar effect, but which is a little less hacky, would be to say that when duping two matches that disagree about "can be default", the "can be default" one must be chosen.  This would probably fix bug 542780.

A tweak to either of these fix variants would be to give the resulting match the original higher relevance score, because we don't want duping to "demote" a match.

Issue 672506 has been merged into this issue.

One other fix would be to say that entries with different inline autocompletions are never dupes.  That's not mutually exclusive with the fix from bug 542780, and makes sense to me in the abstract.  It would mean that if you manually typed URLs like

search.com?q=foo&bar
search.com?q=foo&baz

And then began typing

search.com?q=foo

We would not eliminate the above two entries against each other.  The proposed fix for bug 542780 won't accomplish that; it will merely ensure you get whichever one is best marked as not-a-dupe of the WYT match.  I think filtering these at the deduping stage (as opposed to the overall relevance/ranking sort stage) is incorrect, so this seems like a good fix to me.

So I propose doing both fixes; one on this bug, and one on the other.

Raising priority of this and the related bug 542780, as we've just had yet another instance of this filed.

Issue 725875 has been merged into this issue.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

cc krb@, as the fix for this (see comment #16) is in exactly the same function he's currently touching.  (Submit as a separate changelist please, if you decide to take this up.)

Assigning to krb@, as I think his fixes for bug 879796 and bug 542780 in combination have fixed this one.  Please check sometime.

I don't think I'm able to reproduce this with or without the changes. I backed out those 2 changes, and built up a large history going to "gutenberg.org/ebooks/search/?query=harrison". Even with the old code, when I type "guten", it suggests navigating to those links, and when I keep typing to "gutenberg.org/eb", the top suggestion is that link. gutenberg.org is one of this profile's search engines.

I'm happy to try other things, but it may be easier to ask the reporters to see if they still see it. 725875's seemed particularly adept at it.

I can still reproduce this in version M-69.

I'll assign myself as the owner to verify that it's fixed in more recent versions.

(For reference, regarding reproduction the key is to have an inline autocompletion that doesn't matter for the purposes of computing the stripped destination URL.  I tested by visiting the URL
https://www.amazon.com/s/ref=nb_sb_ss_i_0_4?url=search-alias%3Daps&field-keywords=testing&x=0&y=0&sprefix=agat%2Caps%2C290
many times, mucking with it and then restoring it to make sure the visits count as typed.  Eventually it became inline autocompleted.  The gutenberg example doesn't work because it doesn't have any extra query parameters that would be ignored when computing the stripped destination URL.)

I simultaneously did repro steps on 70.0.3538.35 (Official Build) beta (64-bit) and a top-of-tree developer build.  I could repro in that version of M-70 and could not in top of tree. I think we can declare this fixed!  Thanks for your work on it Kevin.