New issue
Advanced search Search tips

Issue 658085 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Oct 2016
Cc:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug

Blocking:
issue 622481



Sign in to add a comment

Visual differences in text fields after switching to 10.8 deployment target.

Project Member Reported by erikc...@chromium.org, Oct 21 2016

Issue description

See https://bugs.chromium.org/p/chromium/issues/detail?id=622481#c46 and https://bugs.chromium.org/p/chromium/issues/detail?id=622481#c47 for information on why this happens.

It's pretty straight forward to match Chrome's behavior to Safari's. I'm attaching the new and old screenshots from a non-retina screen. The old screenshot is the one with a grey border.
 
Screen Shot 2016-10-20 at 5.36.37 PM.png
7.9 KB View Download
Screen Shot 2016-10-20 at 5.37.55 PM.png
6.1 KB View Download
From a retina device:
Screen Shot 2016-10-20 at 5.38.38 PM.png
14.4 KB View Download
Screen Shot 2016-10-20 at 5.38.45 PM.png
15.0 KB View Download
The non-retina version is the one with the largest change. There used to be a 2-pixel bezeled border. [Outer layer: dark grey, inner layer: light gray]. The new version has a 2-pixel border that has: [Outer layer: slightly darker green, inner layer: white].

On retina, the new behavior has a 1-pixel dark-green border, rather than a 2-pixel grey bezeled border.
If we wanted to, we could use a non-bezeled border, or even just draw the border ourself since we're already drawing the contents without using NSTextFieldCell. We have three real choices:

1) Continue to draw the border using the private method _NSDrawCarbonThemeBezel.
2) Draw the border using NSTextField methods. I've attached a diff that does this. Note that this draws a different border than (1), and also causes different behavior on retina vs. non-retina displays. This still involves changing the frame to draw with on retina displays, since NSTextFieldCell border-drawing doesn't meet the needs of WebCore or Chrome.
3) Just draw the border ourselves. 

I don't think there's sufficient justification to induce a behavior change by switching to (2) or (3).
nstextfield_border.txt
3.6 KB View Download

Comment 4 by rsesek@chromium.org, Oct 21 2016

I'm fine with #1 or #2. It'd be nice to get off the private AppKit function (#2) but I personally prefer the appearance of #1.
Project Member

Comment 5 by bugdroid1@chromium.org, Oct 21 2016

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

commit b882d8b743359ef23639846613c5df1d5a2fb3da
Author: erikchen <erikchen@chromium.org>
Date: Fri Oct 21 02:13:22 2016

Continue to use _NSDrawCarbonThemeBezel to draw text field borders.

No intended behavior change. This CL ensures that when we bump the deployment
target, the behavior remains the same. The alternatives induce behavior changes
for minimal gain. If this ever becomes an issue, it will be easy to switch
solutions.

BUG= 658085 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2

Review-Url: https://chromiumcodereview.appspot.com/2438843003
Cr-Commit-Position: refs/heads/master@{#426688}

[modify] https://crrev.com/b882d8b743359ef23639846613c5df1d5a2fb3da/third_party/WebKit/Source/core/layout/LayoutThemeMac.mm
[modify] https://crrev.com/b882d8b743359ef23639846613c5df1d5a2fb3da/third_party/WebKit/Source/core/paint/ThemePainterMac.mm

Status: Fixed (was: Assigned)
thakis: Please reopen or file a new bug if you think we should change behavior.
Cc: sdy@chromium.org

Sign in to add a comment