Unable to reproduce this issue on Windows-10 using chrome latest stable M59-59.0.3071.86 by following steps mentioned in the original comment. Observed no movements in the suggestion box.

Reporter@ Are you able to reproduce this issue in incognito mode as well? Please let me know what's your screen resolution and are you using HiDpi monitor? Attaching screen cast from my end, Have a look and let me know if anything missing from my end.

Thanks!

Deleted: 731037.mp4 866 KB

	731037.mp4 866 KB View Download

I feel like the problem is related to a "bold" and a "non-bold" space: note that the part of text typed into the omnibox ("numbers" or "numbers ") is non-bold, while the rest is bold in the suggestion. But then, it's only a brief flickering, and and the final rendering after several hundred ms is the same for "numbers" and "numbers ".

I cannot really make out the problem in your screencast, as your top suggestion keeps switching, which is not the case for me. The changes in position are so tiny that they are really only visible when the top suggestion remains the same and you see the immediate horizontal repositioning, as in my video.

I see the issue on my external 1920x1200 monitor, as well as on my 1920x1080 built-in display (same laptop computer). No HiDpi monitor, I guess.

In incognito mode, I cannot reproduce the issue because there are no Google suggestions. Same in guest profile. I have tried an empty profile (no extensions etc, but I find it difficult to reproduce the same suggestions in this one.

Furthermore, I have noticed another issue which may be related, see attached video. In this one, again, I type only space and backspace, and you see "spanish" briefly appear and immediately disappear in the omnibox. This probably unwanted redrawing my be causing the other effect, to.

Deleted: Snap2.webm 1.3 MB

	Snap2.webm 1.3 MB View Download

Note that in #2, I press space only once, and backspace only once, even though at times it looks as if I press backspace twice (once to delete the autocomplete text in the omnibox, and once to delete the previous space).

Thank you for providing more feedback. Adding requester "brajkumar@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

Having switched to google.com (by calling google.com/ncr a couple of times) and having searched for "numbers" a couple of times in an empty profile, I was able to reproduce the original issue starting from an empty profile, with no extensions or anything else.

Able to reproduce the issue on Windows 10, Ubuntu 14.04 and Mac 10.12.5 using reported Stable version #59.0.3071.86, latest stable version #59.0.3071.104 and latest canary #61.0.3135.4.

This is a Regression issue  broken in M-53
Please find the bisect information from below:

Bisect Information:
=====================
Good build: 53.0.2749.0	 Revision(396053)
Bad Build : 53.0.2750.0	 Revision(396337)

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/59d51f9a4cea0fd3d0c27eaf069442b9f556ea9a..d1b22fc961b1a2677c32f61a2a5640850b66adb9

unable to find exact suspect from Changelog
Could anyone from dev team please look into it

Thanks...!!

You said this is not high DPI, but can you confirm your system is set to scale factor 100%?  This looks to me like some sort of RenderText drawing artifact from non-1x scale factors.

Assigning to someone who would know better.

pkasting: Yes, the scale factor is set to "100% (Recommended)" on both external monitor and internal laptop display, and the issue appears on both.

Hmm.  Very strange.  I could imagine this appearing from run breaks in answers or something, but that doesn't look like it would apply in this case.

It seems clear that some of the glyphs are shifting by subpixels.  I don't know why that would be, or who would know the answer.

The bug happens at 1x as well. I dont think this is a HiDPI issue. It seems more like the bold and not bold 'space' character. 

Maybe the issue is that bold space vs. not bold space differ by some number of subpixels, and we rasterize by layout out the glyphs on subpixel bounds, then snapping closer to the pixel grid; that's why it's possible for letters in the middle of the subsequent run to appear to shift.

If that's the case, I don't know what the ideal solution is.  I don't think using a bold vs. non-bold space is really a problem we should fix.  Maybe somebody who's worked closely with font rasterization has a thought, but I don't know who that would be.

We had similar problems in Blink a couple of years ago when we first enabled subpixel positioning. I can't remember exactly how we fixed it off the top of my head but I believe we now align the start of each line box (where the regular text is one line box and the bold part is another one) to a device pixel boundary.

 Issue 719987  has been merged into this issue.

From the merged-in bug,
according to shrike@, on Mac "This happens all the way back to M46 (I didn't check before that). Given that it's been around so long I'm reducing its priority. Marking as Hotlist-PlatformExcellence - this would be a good bug to fix in one of our Mac team fixits."

There's a good chance the regression range listed earlier on this bug is wrong, or at least wrong on Mac.

On the other bug, I noted "I think it might have to do with caching, in AutocompleteResult or in SearchProvider."

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

Still repros.  Comments #13/14 describe the current thoughts on the cause and possible direction for solutions.