This is probably more Omnibox than content suggestions. 
Does this happen on non-iPhoneX as well?

This is actually linked to the clean toolbar. Disabling it fixes the bug.

This is because the animations when contracting the omnibox are starting, and the header view is also updated with the animations, so it takes the animation time to be where it should be.
Just starting then stopping the animations for the contraction as we do in the expand part doesn't work, some ContentSuggestions cells are redrawn on top of other, creating a broken effect.

A possible fix would be to use some orchestrator pattern and have two different code path: the animated code path where the event are put inside the animators and the non-animated code path where the changes are directly called without having animators.

I don't have time to do it now as in implies to rewrite most of the animations.
sczs@, justincohen@: Do you think it should be prioritized?

I don't think we should rewrite most of the animations right now.  Perhaps after refresh?

Just to be clear we need to change the way how animations are handled right? Not rewrite the actual animation code.

Something like this CL could work as a workaround, maybe? https://chromium-review.googlesource.com/c/chromium/src/+/818489 In any case I don't think fixing this is high priority. 

But eventually I agree with gambard@ and we should have some sort of Orchestrator that help us deal with animations timing. 

It is broader than the CL you linked as all the elements currently added to the animator should occur, just not in an animation block.

It is indeed how the animations are handled, there is no problem with the animations.

I am marking this bug available as I don't plan to fix it. For the Adaptive Toolbar I will give the Orchestrator a try and see if it is solving the problem.

I can't reproduce this post refresh, is this still an issue?

Is someone able to reproduce?