New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 617144 link

Starred by 4 users
Status: Fixed
Owner:
█ m...@opera.com
Last visit > 30 days ago
Closed: Jul 2016
Cc:
█ spqc...@chromium.org
█ jole...@opera.com
tapted@chromium.org
pkasting@chromium.org
█ shrike@chromium.org
mac-bugs-priority@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Regression: Results in the Omnibox Dropdown are no longer vertically aligned

Project Member Reported by meh...@chromium.org, Jun 3 2016 
Version: Chrome 53.0.2757.0 canary (64-bit)
OS: OSX 10.11.5

What steps will reproduce the problem?
(1) type something into the Omnibox
(2) Dropdown appears
(3) Take a look at the results

What is the expected output? What do you see instead?
The results are no longer vertically aligned in the Omnibox Dropdown.

Please use labels and text to provide additional information.

This is a Material- and Non-Material issue.

Screenshots are attached.
Bildschirmfoto 2016-06-03 um 15.56.24.png
112 KB View Download
Bildschirmfoto 2016-06-03 um 15.57.56.png
75.2 KB View Download

Comment 1 by meh...@chromium.org, Jun 3 2016

Cc: tapted@chromium.org
Labels: -Needs-Bisect
Owner: m...@opera.com
Status: Assigned (was: Untriaged)
The regression range is between build 397361 and 397369.

mboc@opera.com: It seems that your change (https://codereview.chromium.org/1819753003) is the culprit. Can you please take a look?

Thanks!

Comment 2 by shrike@chromium.org, Jun 5 2016

Cc: shrike@chromium.org
Labels: ReleaseBlock-Beta
This movie shows the bug in action.
JitteryOmnibox.mov
3.0 MB Download

Comment 3 by m...@opera.com, Jun 6 2016

Cc: jole...@opera.com

Comment 4 by meh...@chromium.org, Jun 9 2016 

mboc@: Any plans to fix this regression in near future? Thanks in advance.

Comment 5 by m...@opera.com, Jun 9 2016 

Yes, I will fix it tomorrow.

Comment 6 by meh...@chromium.org, Jun 9 2016 

Great, thanks :-)

Comment 7 by shrike@chromium.org, Jun 11 2016

Cc: spqc...@chromium.org pkasting@chromium.org
 Issue 619247  has been merged into this issue.
Project Member

Comment 9 by bugdroid1@chromium.org, Jun 16 2016 

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

commit 8f451b79fd88739803ce327a315e3d84ea2c752c
Author: joleksy <joleksy@opera.com>
Date: Thu Jun 16 13:52:10 2016

Align the Mac Omnibox items vertically again

OmniboxViewMac::GetBoldFieldFont() needs to request a bold font, then make it larger. Resource bundle will do the opposite, which makes a large system normal font a non-system bold font. That gives a different baseline to making the non-system bold font larger. And while the omnibox locks the baseline in ApplyTextStyle(), OmniboxPopupCellData does not.

BUG= 617144 

Review-Url: https://codereview.chromium.org/2068163002
Cr-Commit-Position: refs/heads/master@{#400144}

[modify] https://crrev.com/8f451b79fd88739803ce327a315e3d84ea2c752c/chrome/browser/ui/cocoa/omnibox/omnibox_view_mac.mm

Comment 10 by mpear...@chromium.org, Jul 28 2016 

Is there anything left to be done on this bug?

Comment 11 by tapted@chromium.org, Jul 28 2016

Status: Fixed (was: Assigned)
I'd say nope.  That workaround means we miss out on some caching and call an expensive function instead, but it's what the Cocoa omnibox was doing before the regression in r397368 anyway.
►

Sign in to add a comment