[Mac] Emoji repaint issue
Reported by
daijiro....@gmail.com,
Jun 19 2018
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3464.0 Safari/537.36 Example URL: https://github.com/watilde/chrome-repaint-cd Steps to reproduce the problem: 1. Put emoji in a tag 2. Set line-height 3. Increment line-height What is the expected behavior? It should not remain the upper of emoji. What went wrong? It remains the upper of emoji. Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? N/A Does this work in other browsers? Yes Chrome version: 69.0.3464.0 Channel: canary OS Version: OS X 10.13.5 Flash Version:
,
Jun 19 2018
Thanks for filing the issue! Navigated to https://github.com/watilde/chrome-repaint-cd on reported chrome version 69.0.3464.0 using Mac 10.13.1 and tried following the steps mentioned in C#0. @Reporter: As we are not very sure about how to put emoji in a tag and then to Set line-height, Could you please elaborate on it which helps us to triage the issue further in a better way.
,
Jul 17
Can reproduce on Mac Chrome 69.0.3493.0 by loading https://watilde.github.io/chrome-repaint-cd
,
Jul 17
This seems to be the wrong bound on the font. I believe that is up to the font system to resolve.
,
Jul 23
Thanks for the report and the test case. drott, looks like we get the bounds of the glyph wrong in this case. Should we perhaps inflate it to guarantee that the repaint bounds are correct?
,
Jul 24
Synthetic bounds inflations are a pain to maintain. We should try to get the correct type of bounds from Skia and CoreText here. I would need to analyse this a bit further, at which font size this occurs. CC bungeman@, FYI. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by krajshree@chromium.org
, Jun 19 2018