Unable to reproduce the issue on reported chrome version #68.0.3440.106 using Windows 10, by following below steps.

Steps:
=====
1.Launched chrome.
2.Navigated to chrome://settings.
3.Added a new search engine with specify keyword as "movie.douban.com" and url as "http://movie.douban.com/subject_search?search_text=%s".
4.Searched for "movie.douban.com" in omni bar, but unable to observe "movie.douban.com_"  as auto complete.

Attached screencast for reference.
@Reporter: Could you please review the attached screen-shot and confirm if anything being missed here .Retry this issue with fresh profile without any extensions and apps , reset all the flags to default and let us know if issue still persists.

Thanks.!

I can not reproduce auto-generated search engine problem.
But the underscore problem can be reproduced.
Then try to visit "movie.douban.com_/" which force chrome visit this invalid domain, i am using a proxy so the proxy tells me it fails with this request.
Then a new history item is recorded so autocomplete will show "movie.douban.com_" in dropdown list, you can see screenshot.
But this item can not be searched so it can not be deleted if several days past.

Deleted: 2018-08-31_004610.png 16.7 KB

	2018-08-31_004610.png 16.7 KB View Download

Deleted: 2018-08-31_004909.png 86.7 KB

	2018-08-31_004909.png 86.7 KB View Download

Deleted: 2018-08-31_004954.png 18.8 KB

	2018-08-31_004954.png 18.8 KB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

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

ayanamist@,

Thanks for the report.

The screenshots posted in comment #4 are hard to make heads or tails of.  In particular, the omnibox screenshot shows a suggestion for the *search query* of movie.douban.com_.  (Notice the magnifying glass next to the suggestion.)  So it's really surprising that you claim the repro steps require attempting to navigate to the URL movie.douban.com_.

I cannot reproduce this, and wonder whether you have a search for movie.douban.com_ in your history.

To help investigate, can you please try two things:
1. try reproducing this in a new profile, and, if you success, post the steps here.
2. Please submit chrome://omnibox output for "movie.douban.c". Check both the “show all details” and “show results per provider” boxes. This will help us figure out what's going on in your current profile.

Feel free to paste the results in here unformatted; we’ll be able to decipher them.

thanks!

Sorry the old issue content misleads you.
The issue is describing "domain with underscore always show in address bar and can not delete", at first i think it's related to search engines, however after some investigations i found it's not related so i remove these parts.

The minimal reproduce steps in 71.0.3542.1 (Official Build) canary-dcheck (32-bit) (cohort: ASAN)
1. On a clean profile
2. Specify a http proxy in system so chrome will use it
2. Visit "www.example.com_/" with underscore and slash
3. Wait and get an error page (screenshot 1)
4. See this access item in history (screenshot 2)
5. Search anything like "www" but can not find this item, so i can not delete this when there are lots of items in history (screenshot 3)

Deleted: screenshot1.png 32.1 KB

	screenshot1.png 32.1 KB View Download

Deleted: screenshot2.png 38.7 KB

	screenshot2.png 38.7 KB View Download

Deleted: screenshot3.png 29.4 KB

	screenshot3.png 29.4 KB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

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

Thanks for the clarification.  I have a theory about what's going on; it's related to the error code returned by the proxy in the case of the failure.  Can you capture a network trace in chrome://net-internals to see what's going on?  thanks!

(In short, open two tabs, open chrome://net-internals in one, switch to the other, attempt to navigate to www.example.com_/, see the error, go back to the net-internals tabs, use the arrow in the top-right to stop recording, then save the trace and upload it here.)

After i see the proxy error, chrome://net-internals/#events is empty, and top-left hints nothing captured. After i stop recording, i got nothing.
Version: 71.0.3544.0 (Official Build) canary (64-bit) (cohort: Clang-64)
Is there any other ways i can help?

Thank you for providing more feedback. Adding the requester to the cc list.

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

Did you load chrome://net-internals/#events *before* doing the failed navigation, and left it open while going to the error page in a new tab?

If so, and you still don't see anything when you return to net-internals after seeing the error page, can you try to navigate somewhere else?  That at least should show up in net-internals, and would verify that net-internals is working for you.

OK, the canary build 71.0.3544.2 (Official Build) canary (64-bit) (cohort: Clang-64) has a broken "net-internals" which can't capture anything.
So i change to a nightly Chromium 71.0.3545.0 (Developer Build) (64-bit) Revision 009656832dbb24663846b39f3a46fd067d13498f-refs/heads/master@{#589393}
Here is the traces which i select all items in events and save right side text to a file.

Deleted: traces.txt 455 KB

traces.txt 455 KB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

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

Hi ayanamist@,

Thanks for the trace!

apologies for repeated questions but just making sure the bug doesn't go in different directions:
-Is the current problem in this bug that there are history items you cannot search for?
-The underscore issue and search engine problem are solved, correct?


Hi mpearson@
relevant lines in the trace file start around 8590.

My first thought was that the proxy might be returning a 2xx success code, or something that could cause the page to be saved to history. Was that similar to your theory?

It's a legitimate server error:
HTTP/1.1 504 Connection failed
However, since the document has content we may log the visit? The difference between example.com_ with and without the MEOW proxy here is probably that without the proxy it might fail at DNS resolution, but having the proxy may allow it to proceed further and get a failed HTTP request?

I forget if we can (policy-wise) set up mitm proxies so I visited a couple sites people have helpfully built to return arbitrary error codes. I think it causes a behavior similar to what ayanamist@ is seeing:

http://httpstat.us/504
http://504.returnco.de/one/two/three

In both cases, the pages are added to the history page but I'm unable to search for them in chrome://history. I can still delete them of course, but as mentioned here it requires manually scanning the results.

Resolutions 
-----------
If the underscore behavior bit is still relevant, we may be able to dupe that piece to 823314. 
If the history bit is the extent of the bug, this may not be an omnibox component bug (maybe UI>Navigation and history components). Didn't immediately see something to dupe to but may have missed one.

Yes the current problem in this bug is that there are history items i cannot search for.
Yes the underscore issue and search engine problem are solved.

thanks, I don't think this is an omnibox bug so moving to history.

History folks, potentially easy repro (hopefully covers the entire bug) is to visit one or both of
  http://httpstat.us/504
  http://504.returnco.de/one/two/three
then try to search for them in chrome://history. They're filtered out on searching.

As far as I can tell, this is intentional.  URLs that resulted errors are marked as "hidden" (literally, that's the name of the field) and generally not shown in UIs.

  // Top-level frame navigations are visible; everything else is hidden.
  // Also hide top-level navigations that result in an error in order to
  // prevent the omnibox from suggesting URLs that have never been navigated
  // to successfully.  (If a top-level navigation to the URL succeeds at some
  // point, the URL will be unhidden and thus eligible to be suggested by the
  // omnibox.)
  const bool hidden =
      !ui::PageTransitionIsMainFrame(navigation_handle->GetPageTransition()) ||
      status_code_is_error;
https://cs.chromium.org/chromium/src/chrome/browser/history/history_tab_helper.cc?sq=package:chromium&g=0&l=76-84

I guess we could introduce a notion of a top-level navigation that resulted in an error (that's not suitable for the omnibox though is suitable for history).  I don't think it's worth the trouble.

History hides error access, that's fine. But the error access also needs to be hidden in omnibox too.
And they are not hidden in history yet, but just be hidden in history search result, i dont think these inconsistent should be intentional.

CC sky@ jkrcal@ for the question below.

I agree, it's odd that they're inconsistent.

It looks like the default chrome://history page filters out certain types of transitions, yet leaves "hidden" visits shown.
https://cs.chromium.org/chromium/src/components/history/core/browser/visit_database.cc?type=cs&g=0&l=387-393

Meanwhile, the chrome://history page that results from a search has the search populated by this query, which explicitly excludes "hidden" visits.  It also seemingly doesn't filter by transitions.
https://cs.chromium.org/chromium/src/components/history/core/browser/url_database.cc?type=cs&g=0&l=385

sky@ or jkrcal@, is this inconsistency intentional?

I cannot talk for the history DB. I think the inconsistency is due to querying different tables - trying to avoid joining the tables in the SELECTs.

sky@ should know more.

I think it's by design that the two are not consistent. chrome://history is intended to be a log of almost all navigations, including those that resulted in an error. For example, I think it would be weird if you typed in an invalid user and that didn't show up on chrome://history. OTOH the url database generally doesn't want to autocomplete to error pages, even if the user typed it in.