Omnibox popup mispositioned on scale factors >1 due to DIP conversions |
|||||
Issue descriptionBecause the omnibox popup uses a screen-coordinate-positioned widget, and all our coordinates are in DIPs, when the scale factor is >1 the widget can be mispositioned up and/or left by up to (scale_factor - 1) px, depending on where the browser window is placed onscreen. With things in the dropdown trying to line up precisely against the omnibox above, this looks bad. I doubt this needs to be a widget anymore, since it doesn't use transparency (and even if it did we could still probably find a way to avoid making it a widget). This should probably be converted to a view owned by the BrowserView, created near-last in the child order (i.e. right by the find bar host view) so it draws above everything else. This would let the browser set the origin and width correctly and leave the popup only responsible for computing its height. Overall, this ought to simplify the code (due to not having to plumb so much positioning info to the popup) in addition to fixing the issue above. CCing a few folks working on DPI-related stuff that might want to tackle this.
,
Aug 30 2016
From an email I had sent to Bret regarding the status bubble code: "I bet if we modified RepositionPopup() to get at the window tree host (using something like what DesktopNativeWidgetAura::SetBounds() does) we could get the parent and set the child coordinates, all in pixels. I think views code can assume Aura at this point, although I'm not 100% sure. This is obviously a hack around the normal pipeline, but if we figure it out, we can use it for the omnibox popup too, and it's a lot easier than trying to fix the entire views system to use pixels everywhere or store DIPs as non-integral values."
,
Nov 23 2016
,
Apr 19 2017
Issue 712104 has been merged into this issue.
,
Jun 16 2017
,
Sep 21 2017
,
Sep 21
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
,
Sep 24
tommycli: can you verify whether this issue still exists or not? |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by bsep@chromium.org
, Aug 30 2016