Issue 666354 has been merged into this issue.

(+helenepark as FYI)

Notes:  Issue https://bugs.chromium.org/p/chromium/issues/detail?id=666354 has a video demonstrating the problem.

The problem is not only with vertical movement but also horizontal.

In my experience, the movement is tied to the update of the content of the drop-down more than the characters being typed.  That is, if the suggestions don't change when you type another character, the box doesn't move.

It does indeed sound like it could be related to 620218.

 Issue 693939  has been merged into this issue.

This motion jank makes the omnibox feel less robust and less trustworthy. On my XPS 13, in particular, it's quite noticeable. It may be an issue for other fractional scale factors too (not just 1.5). So some extra investment here would definitely have my support. 

Adding a screenshot at scale factor 2.5. The top divider of the dropdown sits 4px (image 2,4), then 6px (image 3) too high.

Deleted: Dropdown 2.5x.png 67.7 KB

	Dropdown 2.5x.png 67.7 KB View Download

The top being as high as it is in images 2 and 4 is actually expected, but I hate the intention.

It's an artifact of:

(1) The omnibox being drawn as overlapping part of the toolbar and shadowing over it.  I argued with sgabriel when we did top chrome MD that we should just share the toolbar bottom divider, but I lost.  I still think we should do that though :)

(2) DIPs-vs.-px; we can only lay out in DIPs, and then rounding kicks in as well.

Only the shift up in image 3 is this bug.

Whoa?? You're down with sharing the border (1)?

Because both Max and I preferred that, but we kiboshed that kinda thinking: "Oh Peter must have his reasons... let's pick our battles".

If all three of us are in agreement with sharing the border in Views (it already shares the border on Mac), let's just change that today.

Tommy

Haha.  Many things in Chrome today, including things I own, are not the way I'd prefer them to be :).  I never really understood why Sebastien was so keen on doing things this way.  Feel free to reach out and ask him if you want :)

I'm going to assign to myself for now because I'm dealing with related stuff.

OK, but note that this bug isn't about sharing the border but rather about fixing the shifting.  To do that, the best way would be to figure out how to make the omnibox dropdown a child view in the same widget as everything else.  I don't know whether that's possible.  The alternate is that you figure out something crazy to bypass the dip-to-px conversion errors we currently have.

I think I'm fixing this in https://chromium-review.googlesource.com/c/chromium/src/+/981970

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/43fdbea70216927d5b53a063ddbf81e6dbee373c

commit 43fdbea70216927d5b53a063ddbf81e6dbee373c
Author: Trent Apted <tapted@chromium.org>
Date: Wed Mar 28 01:14:24 2018

Fix omnibox dropdown bounds setting on non-integral scale factors

Care needs to be taken when querying the current Widget bounds since
it may be rounded up from a prior call to SetBounds() on screens with
non-integral scale factors.

To fix, never ask the Widget for its current bounds. Instead, just
assume the last *set* bounds is where the shrink animation should start
from.

Bug:  824627 ,  629363 
Change-Id: I6914f5a779ff57f9fa1c10aefcd04579784d73ca
Reviewed-on: https://chromium-review.googlesource.com/981970
Commit-Queue: Trent Apted <tapted@chromium.org>
Reviewed-by: Peter Kasting <pkasting@chromium.org>
Cr-Commit-Position: refs/heads/master@{#546354}
[modify] https://crrev.com/43fdbea70216927d5b53a063ddbf81e6dbee373c/chrome/browser/ui/views/omnibox/omnibox_popup_contents_view.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8bc9cf9d0e9f6d22768a8c60fb8ff29b9fa87551

commit 8bc9cf9d0e9f6d22768a8c60fb8ff29b9fa87551
Author: Trent Apted <tapted@chromium.org>
Date: Thu Mar 29 21:06:32 2018

[merge-m66] Fix omnibox dropdown bounds setting on non-integral scale factors

Care needs to be taken when querying the current Widget bounds since
it may be rounded up from a prior call to SetBounds() on screens with
non-integral scale factors.

To fix, never ask the Widget for its current bounds. Instead, just
assume the last *set* bounds is where the shrink animation should start
from.

Bug:  824627 ,  629363 
Change-Id: I6914f5a779ff57f9fa1c10aefcd04579784d73ca
Reviewed-on: https://chromium-review.googlesource.com/981970
Commit-Queue: Trent Apted <tapted@chromium.org>
Reviewed-by: Peter Kasting <pkasting@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#546354}(cherry picked from commit 43fdbea70216927d5b53a063ddbf81e6dbee373c)
Reviewed-on: https://chromium-review.googlesource.com/986952
Reviewed-by: Trent Apted <tapted@chromium.org>
Cr-Commit-Position: refs/branch-heads/3359@{#505}
Cr-Branched-From: 66afc5e5d10127546cc4b98b9117aff588b5e66b-refs/heads/master@{#540276}
[modify] https://crrev.com/8bc9cf9d0e9f6d22768a8c60fb8ff29b9fa87551/chrome/browser/ui/views/omnibox/omnibox_popup_contents_view.cc

Able to reproduce this issue on build without fix(Checked on 66.0.3356.0) when scale factor is 225 on HIDPI windows machine. Hence verifying fix on latest beta 66.0.3359.81.

Now not observing any shift when typing in omnibox. Attaching screencast for reference.

As fix is working as expected adding verified labels.

Thanks!

Deleted: 629363_66.0.3359.81.mp4 658 KB

	629363_66.0.3359.81.mp4 658 KB View Download