New issue
Advanced search Search tips

Issue 799333 link

Starred by 3 users
Status: Available
Owner: ----
Cc:
behdad@chromium.org
drott@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 3
Type: Bug
M-X



Sign in to add a comment

on macOS 10.10, zero-width spaces in the system font rendered with Harfbuzz using system kerning have non-zero width

Project Member Reported by tapted@chromium.org, Jan 5 2018 
Chrome Version       : 65.0.3311.0
OS Version: OS X 10.10

And on other macOSes they maybe have a tiny negative space still?

One way this seems to manifest is as follows:

The string below is an x followed by a zero-width space:

"x​"

Copy it into a <textarea>, put the cursor to the LEFT of the x and press the right arrow once so the cursor is between the x and the zero-width space.

Then, press shift+right.

Expected: Nothing should get selected (since it's the zero-width space).
Actual: The x gets selected.


This happens with system fonts (monospace, courier, BlinkMacSystemFont). But not with non-system fonts (e.g. "courier new", arial).

Tested 10.9, 10.10, 10.12 with 65.0.3309.0 or 65.0.3311.0 and they all do this.

63.0.3239.84 also does this, so this doesn't seem to be a recent regression.



The issue that's more apparent will manifest once http://crrev.com/c/851293 lands, but only on 10.10.

Repro: open the (toolkit-views) bookmark bubble and paste '"x​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​"' into the Name field. That's an x followed by a bunch of zero-width spaces.

Expected: The closing quote should come right after the 'x'
Actual: There's a big gap - see attached


Since this is really corner-casey, and 10.10 won't be around much longer, fixing this doesn't seem high priority.
Screen Shot 2018-01-05 at 1.04.27 pm.png
74.0 KB View Download
Project Member

Comment 1 by bugdroid1@chromium.org, Jan 8 2018 

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

commit eff6931b804c3da1e76a2553f07a66ff0c8ace28
Author: Trent Apted <tapted@chromium.org>
Date: Mon Jan 08 03:14:54 2018

Reland: Mac RenderTextHarfBuzz: Use hb_coretext_font_create().

The HarfBuzz roll in r513541 improved Mac UI font support in the
renderer by detecting UI fonts and invoking CTFontCreateUIFontForLanguage().

However, in chrome UI, there is already a CTFont wrapped in a gfx::
PlatformFont for UI fonts. So creating a new CTFont for every hb_shape
call becomes unnecessary and expensive.

hb_coretext_font_create() (after a hb_coretext_face_create()) allows
the steps requiring the call to CTFontCreateUIFontForLanguage() to
be skipped by associating the CTFont with the hb_font_t directly.

Adds a new views_perftest target and LabelPerfTest.GetPreferredSize
to track. On a Late 2013 Mac Pro perf improves from 1390 runs/second
to 3300 runs/second.

+250 runs/second of that comes from a related hotspot in gfx::internal::
CreateSkiaTypeface() which was deriving a new CTFont unnecessarily
before sending it to gfx::CreateHarfBuzzFont().

Reland of r526920 with workarounds for some buggy system font data affecting
some low-priority corner cases on specific macOS versions.

Bug:  785522 , 799333
Change-Id: I02c6e47edfdd759fe477a61fe399a541a4a7ce3e
Reviewed-on: https://chromium-review.googlesource.com/851293
Reviewed-by: Michael Wasserman <msw@chromium.org>
Commit-Queue: Trent Apted <tapted@chromium.org>
Cr-Commit-Position: refs/heads/master@{#527559}
[modify] https://crrev.com/eff6931b804c3da1e76a2553f07a66ff0c8ace28/ui/gfx/font.cc
[modify] https://crrev.com/eff6931b804c3da1e76a2553f07a66ff0c8ace28/ui/gfx/harfbuzz_font_skia.cc
[modify] https://crrev.com/eff6931b804c3da1e76a2553f07a66ff0c8ace28/ui/gfx/render_text_unittest.cc
[modify] https://crrev.com/eff6931b804c3da1e76a2553f07a66ff0c8ace28/ui/views/BUILD.gn
[modify] https://crrev.com/eff6931b804c3da1e76a2553f07a66ff0c8ace28/ui/views/DEPS
[add] https://crrev.com/eff6931b804c3da1e76a2553f07a66ff0c8ace28/ui/views/controls/label_perftest.cc
[add] https://crrev.com/eff6931b804c3da1e76a2553f07a66ff0c8ace28/ui/views/views_perftests.cc

Comment 2 by behdad@google.com, Jan 8 2018 

Does Safari do the same?  Sounds like a bug in how CoreText applies the 'trak' table.

Comment 3 by tapted@chromium.org, Jan 9 2018 

Safari works correctly for the default font on textarea.org (Bitstream Vera Sans Mono?).

But it gets more bizarre when the default user agent stylesheet font is used, or explicitly "-apple-system;", or arial.. It seems to merge all the zero-width spaces into a ~ligature of sorts, and makes cursor positions all across the glyph that preceeds the zero-width spaces.

E.g. with just one zero width space, cursoring over the 'x' only goes half way (highlighting the zero-width space highlights the second half of the 'x')
Screen Shot 2018-01-09 at 2.21.58 pm.png
18.3 KB View Download

Comment 4 by behdad@google.com, Jan 9 2018 

We simply return what CoreText returns.

Can someone reproduce this using hb-shape?  Perhaps I need to implement --font-ptem first.

Comment 5 by ellyjo...@chromium.org, Mar 26 2018

Labels: MacViews-Controls M-X
MacViews triage: M-X. This is a super corner case in 10.10 only.

Comment 6 by robliao@chromium.org, Jul 12

Labels: Group-Visual_Defects
►

Sign in to add a comment