Unable to reproduce the issue on Windows 10,Mac 10.12.4 & Ubuntu 14.04 using chrome stable-57.0.2987.133 & Canary-59.0.3066.0 as per steps mentioned in comment#0.Observed that page reloaded successfully.
Please find the attached screencast for reference & let us know if we miss anything to reproduce the issue.
Thank you!!

Deleted: 708085.mp4 2.0 MB

	708085.mp4 2.0 MB View Download

Thanks for the attention.
I guess it depends on how fast is the hardware to load the history from the storage or network when focus goes on the address bar.
I usually use Google and my history around Google domain is more than Yahoo, In the attached video you can see the problem is more clear when I try to represent the problem in Google.

Deleted: Video_2017-04-12_195430.wmv 1.5 MB

Video_2017-04-12_195430.wmv 1.5 MB Download

Thank you for providing more feedback. Adding requester "jmukthavaram@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

Rerouting to Network team for further triage.

Thanks,

I watched the video, but couldn't quite understand what the issue is.

Is it responsiveness of the URL box, or slowness loading the page?
Is it the same if you do a reload (ctrl-R) instead?

Why are you confident that "Use a prediction service" is causing the slowness here?

Why do the steps say to press enter quickly rather than slowly?  Does the problem not recur if you press enter slowly?

Does the problem occur on all pages?  Does it occur on a clean profile?

Where the problem occurs, if you press alt-D _without_ pressing enter, what happens?  Does a popup appear below the omnibox?

eroman@chromium.org:
- It is responsiveness of the URL box.
- Ctrl-R works fine and immediately reloads the page.
Here is what I expect: After focusing on the URL box (with mouse click on it or Alt-D) and then pressing the Enter key below about 300-400ms after that focusing, page should be reloaded.

pkasting@chromium.org:

1- Once I turned that service off, the problem will be solved.

2- After the omni-box got focused (with prediction service ON) and Enter key pressed `after` about 300-400ms page will be reloaded normally. but before that number It just do nothing.
(These `300-400ms` number maybe depends on my computer hardware, network speed, distance to the server, amount of my browsing history, ... ) 

3-A: No. I think websites that are viewed more than the others affects directly on the problem. For example I use google more than yahoo, so this problem when yahoo page is opened not shows itself.

3-B: It doesn't occur in a clean profile.

4- No. nothing happened.

Thank you for providing more feedback. Adding requester "eroman@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

Wait, you're saying that if you focus the address bar and press enter too quickly the page _never_ reloads?  Or it just takes longer to reload?

If you try the steps that reproduce this problem, but with some slow-loading page in a background tab so it has a spinning throbber, does the throbber pause or hitch after you press enter?

Mark, do we have histograms that could capture any zerosuggest-related delays?

Reading through this issue, I'm inclined to think it should be driven from the Omnibox side and if there's a network tie-in it'll be discovered after some digging in that space.  Removing "Internals>Network" on that basis, but Ominbox folks/Peter, please feel free to re-add if you disagree with this assessment. 

pkasting@chromium.org:

1- It _never_ reloads.

2- There is no difference if any other tabs are being loaded at the same time.
Also no matter if the current tab is loading right now or not, _In-Some-Websites_ focusing on the OmniBox and immediately pressing enter key won't works.
If the current page is of kind of that pages which causes this issue, no matter how many times you press the enter. It just doesn't work. But right after 300-400ms that the OmniBox is focused, next enter key that you press will works and previous keypress ones will be discarded.

I don't know what circumstances are related to the websites that cause this issue on the browser and I didn't find any rule or condition.

For more clarification I send you another captured video.

Deleted: converted_b229d7fa_converted.mp4 9.6 MB

	converted_b229d7fa_converted.mp4 9.6 MB View Download

Hmm.  The number of times the Chrome menu is popping up -- which is what happens when we register "alt" followed by "enter", with no "d" -- coupled with the lack of flash of "d" on the OSK -- is making me wonder if this isn't some kind of issue of Chrome getting the wrong event stream, which could be caused by anything from a Chrome bug to a Windows bug to a failing physical keyboard to user error.

That would not explain why you see this issue more frequently when signed in with "use a prediction service" on.

I wonder what you would see if you hit "down" before hitting enter in these cases.

I have no idea how to debug this or proceed forward here.

Does it reproduce in the same way if you use "ctrl-L" instead of "alt-D" ?

pkasting@chromium.org:
- That's my fault in pressing keys, because in that cases I didn't press D correctly when Alt is down and menu shows up.
- Pressing `down` acts exact like Enter and don't work for the first time in some websites.

eroman@chromium.org:
- Ctrl-L, Alt-D, Focus by mouse click,... are the same.

Thanks for the report.

If you have a tab that reproduces this issue, can you please open a new tab, go to chrome://histograms, and save the output of that page.  Then switch back to the previous tab, focus the omnibox (don't press enter), then return to the chrome://histograms.  Reload this page (using the icon, not by focusing on the omnibox).  Save the output of the page.  Then upload both those histograms pages' outputs here.  The difference between them--what was recorded in the middle when you did the omnibox focus--should be able to tell us something.

thanks for your help investigating this wonky issue!

Here are what you ask:

01.html:
-- I opened example.com (that have the issue), then histogram, and saved the result.

02.html:
-- I focused on the `example.com` omnibox, then returned to the histogram tab, refreshed with refresh icon and saved the result.

Thanks in advance.

Deleted: 01.html 825 KB

01.html 825 KB View Download

Deleted: 02.html 1.1 MB

02.html 1.1 MB View Download

pkasting: I don't see any high counts (lengths of time) in the Omnibox.ProviderTime2.* histograms, so whatever slowdown here isn't due to the AutocompleteController and its providers.

Oh, how rude I was!

THANK YOU mohammad for providing those histograms.

If things never load if keys are hit too quickly, then there's no slowdown issue.  It would be a different kind of issue entirely, such as events getting dropped somewhere in the pipeline.

mohammad.bagherani@,

Reading this over now makes me wonder if this is a prerender/preload issue.  We dramatically revamped this code in Chrome 58 and 59.  Can you still reproduce this issue with the current version of Chrome?

thanks,
mark

mohammad.bagherani@,

Can you still reproduce this issue?  We haven't heard any additional reports like this so we'll need more help from you to investigate.

Hi,
I updated to Chrome 60, It seems its getting better but not fully solved (maybe delay is decreased to 100-200 ms).
Here is my histogram files (like comment #19)

Deleted: About Histograms1.html 825 KB

About Histograms1.html 825 KB View Download

Deleted: About Histograms2.html 938 KB

About Histograms2.html 938 KB View Download

Thank you for providing more feedback. Adding requester "mpearson@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

I still don't see any oddities in the histograms files.  If it doesn't appear in a clean profile, can you try disabling all extensions and see if it reproduces within your problematic profile?

Also, can you post your who about:version data here, including the big Variations: section?

thanks!

mohammad.bagherani@,

Are you still experiencing this issue?

No replies from the original reporter.  Closing.  Happen to investigate further if you provide the information in comment #27.

Reply to #27 -> version file attached in fileupload #1. (Windows 8.1, Intel Core-i5, 8GB RAM).
Reply to #28 -> Yesss. (I'm using chrome 64).
Reply to #29 -> Am I the only one having this issue in the entire globe?
Ref to Comment 3, 12, 25 the problem still exists and no improvement happened and I'm wondering how it doesn't happened to you!

Deleted: About Version.html 4.4 KB

About Version.html 4.4 KB View Download

I also have the same problem