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

Issue 786786 link

Starred by 2 users
Status: Fixed
Owner:
drott@chromium.org
Closed: Nov 2017
Cc:
kojii@chromium.org
js...@chromium.org
█ sc00335...@techmahindra.com
e...@chromium.org
drott@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

Metrics for Emoji wrong on Chrome

Project Member Reported by markda...@google.com, Nov 19 2017 
Chrome Version       : Version 62.0.3202.94 (Official Build) (64-bit)
(on macOS Sierra, Macbook Pro

URLs (if applicable) : http://www.unicode.org/emoji/charts/emoji-style.html

Other browsers tested: Safari OK Version 11.0.1 (12604.3.5.1.1)

What steps will reproduce the problem?
(1) open the URL
(2) look at the chart. Each emoji is listed with CSS showing the advance width


What is the expected result?

images don't exceed the bounding box (as in Safari)

What happens instead?

images exceed the bounding box, causing collisions

Please provide any additional information below. Attach a screenshot if
possible.
Chrome Screen Shot 2017-11-19 at 12.21.08.png
491 KB View Download
Safari Screen Shot 2017-11-19 at 12.22.00.png
399 KB View Download

Comment 1 by js...@chromium.org, Nov 20 2017

Cc: js...@chromium.org drott@chromium.org kojii@chromium.org e...@chromium.org
Components: Blink>Layout Blink>Fonts>Emoji
Labels: OS-Mac

Comment 2 by js...@chromium.org, Nov 20 2017

Labels: -Restrict-View-Google

Comment 3 by js...@chromium.org, Nov 20 2017 

Somehow I can't reproduce the issue. See the attached screen shot taken of the same Unicode page with 62.0.3202.94 (Official Build) (64-bit) on macOS 10.12.6.
Screen Shot 2017-11-19 at 6.26.28 PM.png
1.0 MB View Download

Comment 4 by js...@chromium.org, Nov 20 2017

Labels: allpublic

Comment 5 by drott@chromium.org, Nov 20 2017 

See also  issue 784780 , where emoji spacing has improved in Chrome 64.

Comment 6 by sc00335...@techmahindra.com, Nov 21 2017

Cc: sc00335...@techmahindra.com
Labels: hasbisect-per-revision ReleaseBlock-Stable Triaged-ET M-63 Needs-Triage-M62 Pri-1 Type-Bug-Regression
Owner: drott@chromium.org
Status: Assigned (was: Unconfirmed)
Able to reproduce this issue on reported version 62.0.3202.94 but fixed on latest canary 64.0.3274.0 using Mac 10.13.1 using steps mentioned in comment#0, it's specific to Mac OS. Hence providing reverse bisect info.

Reverse Bisect Info:
=================
Last Bad Build: 64.0.3257.0
First Good Build: 64.0.3258.0

You are probably looking for a change made after 513744 (known good), but no later than 513745 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/5877a5b752d3cb6a84b07caf92eb69eecc0854ef..487f920d800195ee2d5de599ac0f647720627dc4

Probably fixed by  https://chromium-review.googlesource.com/718860

@drott: Could you please confirm if its safe to merge to M-63.

Adding RB-Stable for M-63. Please feel free to remove if not the case.

Thanks!

Comment 7 by drott@chromium.org, Nov 21 2017

Labels: -Pri-1 -ReleaseBlock-Stable Pri-2
Please mind the tagging, this is not a recent regression, and it also does not warrant RB-Stable, I am not sure why you added these tags.

This change cannot be merged to M-63, it needs testing in Beta, it's dependent on a HarfBuzz roll that we're currently investigating for performance issues.

Comment 8 by js...@chromium.org, Nov 21 2017

Labels: -Type-Bug-Regression -M-63 -Needs-Triage-M62 Type-Bug
And, this is not a regression, either. 

Removing M-63 and Needs-Triage-M62 labels.

Comment 9 by js...@chromium.org, Nov 21 2017

Status: Fixed (was: Assigned)
Fixed in ToT and will be a part of M64.
►

Sign in to add a comment