New issue
Advanced search Search tips

Issue 711161 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: Apr 2017
Cc:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug



Sign in to add a comment

views::[Styled]Label adds insets for focus rings on Links, even when it never draws them

Project Member Reported by tapted@chromium.org, Apr 13 2017

Issue description

This throws off layout since all the text gets shifted down by 1px for focus rings that will never be drawn.

Chrome Version       : 59.0.3047.0

>> 2. Less related to line-spacing specifically, but the text_bounds are not aligned to the "content_bounds"...from what I can tell. That ultimately increases what should be 8pt between title and body text to ~10px. Is this to be expected or is this related to the font-size and/or leading offset tables? 

<quote>
I haven't dived in completely, but here's what I *think* is happening: That text is rendered with views::StyledLabel, which makes a views::Label for each line and a separate views::Link for each clickable link. views::Link is focusable, so it needs to draw a focus ring (except in Harmony, when it doesn't have one -- it gets an underline instead). That old-style focus ring causes views::Link to say "I need 1px more space", at 

gfx::Insets Label::GetInsets() const {
  gfx::Insets insets = View::GetInsets();
  if (focus_behavior() != FocusBehavior::NEVER) {
    insets += gfx::Insets(kFocusBorderPadding, kFocusBorderPadding,
                          kFocusBorderPadding, kFocusBorderPadding);
  }
  return insets;
}

kFocusBorderPadding is 1 DIP.

Then StyledLabel::CalculateAndDoLayout() notices that one of the rows needs more space, and makes room for it. I'm pretty sure this accounts for ay least some of the discrepancy - maybe all of it.

The fix should be straightforward. Since views::Label does not get a focus ring under Harmony, we just need to update Label::GetInsets() to account for that properly.
</quote>

"fix should be straightforward". He laughs. This is a bit of a rats nest..

I've made a start - https://codereview.chromium.org/2810403002
 
popup_view.png
18.6 KB View Download
bookmark_signin_promo.png
18.0 KB View Download
Project Member

Comment 1 by bugdroid1@chromium.org, Apr 21 2017

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

commit 480f457f6939eade256dc987fd740452ef5912de
Author: tapted <tapted@chromium.org>
Date: Fri Apr 21 01:25:05 2017

Views: Don't add insets for views::Link focus rings under MD.

Insets for dashed focus rings are throwing off the text alignment on
dialogs. Currently they are added to any Link and any StyledLabel that
contains a Link.

Dashed focus rings have already been phased out from most places in
Chrome. On a views::Link, they are still needed when the link is
permanently underlined since that's the only way to indicate focus.

To contain the insanity, this CL makes assumptions (both with and
without MD).

- only views::Link ever wants a focus ring - not vanilla views::Labels
(effectively, a vanilla Label is never focusable).

- If a views::Link consumer calls SetUnderline(true) then it wants a
focus ring (even under MD). This happens (sometimes) for the
BookmarkBarInstructionsView and nothing else.

- If SetUnderline is not called it wants the "default"

- Nothing overrides Label::GetInsets to add things that are not focus
rings (StyledLabel was already making this assumption).

- Under MD only, views::StyledLabel consumers never want underlines on
links (this is currently the case).

- Under Non-MD only, calling SetUnderline(false) removes the underline
but does not change the focus style.

This allows a lot of the "focus ring" logic to move down into
views::Link where it will be easier to delete later. Calculating the
bounds stays in views::Label since it inspects Label's private
RenderText instances.

BUG= 711161 

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

[modify] https://crrev.com/480f457f6939eade256dc987fd740452ef5912de/chrome/browser/ui/views/harmony/layout_provider_unittest.cc
[modify] https://crrev.com/480f457f6939eade256dc987fd740452ef5912de/ui/views/controls/label.cc
[modify] https://crrev.com/480f457f6939eade256dc987fd740452ef5912de/ui/views/controls/label.h
[modify] https://crrev.com/480f457f6939eade256dc987fd740452ef5912de/ui/views/controls/label_unittest.cc
[modify] https://crrev.com/480f457f6939eade256dc987fd740452ef5912de/ui/views/controls/link.cc
[modify] https://crrev.com/480f457f6939eade256dc987fd740452ef5912de/ui/views/controls/link.h
[modify] https://crrev.com/480f457f6939eade256dc987fd740452ef5912de/ui/views/controls/styled_label.cc
[modify] https://crrev.com/480f457f6939eade256dc987fd740452ef5912de/ui/views/controls/styled_label_unittest.cc

Comment 2 by tapted@chromium.org, Apr 21 2017

Status: Fixed (was: Started)

Sign in to add a comment