Issue metadata
Sign in to add a comment
|
Regression: Font issue is observe in Omnibox.
Reported by
abom...@etouch.net,
Jun 20 2017
|
||||||||||||||||||||||
Issue descriptionChrome Version:61.0.3136.0 (Official Build) fa10d4397863ac2df5724e53131b3e61a0d0ebb4-refs/heads/master@{#480665} OS:Mac (10.12.6,10.11.6) What steps will reproduce the problem? 1. Launch chrome and navigate to chrome://version/,chrome://settings/help (any internal page) 2. Observe font of ‘chrome://‘ word. Actual: Font issue is observe in Omnibox. (i.e. Thin/Faint ‘chrome://‘ is seen.) Expected: Font issue should not be seen This is regression issue, broken in ‘M 61’ and below is manual bisect info: Good build:61.0.3135.4 Bad build:61.0.3136.0 Note: Issue is not seen on Window and Linux OS.
,
Jun 20 2017
Yep — it only worked before due to a macOS bug which we no longer trigger. I'm going to try to find a good way to bring back proper text smoothing.
,
Jun 20 2017
Adding blocker label, since this is a recent regression. Please remove if not the case. Thanks.!
,
Jun 22 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/4d77c849b825d8520ec86ec053d0962607d7fab9 commit 4d77c849b825d8520ec86ec053d0962607d7fab9 Author: Sidney San Martín <sdy@chromium.org> Date: Thu Jun 22 05:55:57 2017 [Mac] Bring back subpixel AA while the omnibox is being edited. This regressed in r480444, which wrapped the tab strip's NSVisualEffectView in another view so that it won't be asked for (often incorrect) hints about text smoothing. Without the hints, many AppKit controls disable subpixel AA if subclasses override drawing methods or draw text themselves. This could be considered an AppKit bug — the behavior should be the same with/without an NSVisualEffectView in play. This change sets `drawsBackground = NO` on the field editor and stops overriding `drawViewBackgroundInRect:` and `isOpaque`, which makes NSTextView opt back into subpixel AA. We'll need to make the same kinds of changes in other places, the omnibox is just the most glaring one. Bug: 734922 Change-Id: I7e604d862f54bf5b4d122566664baeca3d98bae4 Reviewed-on: https://chromium-review.googlesource.com/544196 Reviewed-by: Trent Apted <tapted@chromium.org> Commit-Queue: Sidney San Martin <sdy@chromium.org> Cr-Commit-Position: refs/heads/master@{#481458} [modify] https://crrev.com/4d77c849b825d8520ec86ec053d0962607d7fab9/chrome/browser/ui/cocoa/location_bar/autocomplete_text_field_cell.mm [modify] https://crrev.com/4d77c849b825d8520ec86ec053d0962607d7fab9/chrome/browser/ui/cocoa/location_bar/autocomplete_text_field_editor.mm
,
Jun 22 2017
This missed today's Canary but should be in tomorrow's (61.0.3139.0).
,
Jun 27 2017
With response to comment #6: Above issue is still reproducible on Latest Dev Chrome Version: 61.0.3141.0 (Official Build) 180095eb1bca7df1cdcb02547340499c2ee3af6e-refs/heads/master@{#482153} and Latest Canary Version:61.0.3142.0 (Official Build) using Mac Pro (10.12.3) Please find the attached screencast and screenshot:
,
Jun 27 2017
Re. #7, I can see a slight difference in the screenshot. I cannot see a difference in the movie. The antialiasing is lighter now because it's using the white background of the omnibox instead of incorrectly grabbing an off-white color from the translucent NSVisualEffectView behind the tab strip. If there's a bigger difference that I'm not noticing, could you tell me more about what it is?
,
Jun 27 2017
(The gif attached to #8 is animated, you may have to click on it to see it animate.)
,
Jun 28 2017
With respect to comment #8 and #9: Yes, It's a slight difference and it maybe because of white background of the omnibox
,
Jul 11 2017
Note: Above issue is fixed on latest Dev version 61.0.3153.4 for MAC OS (10.12.3) |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by abom...@etouch.net
, Jun 20 2017Labels: hasbisect
Owner: sdy@chromium.org
Status: Assigned (was: Unconfirmed)