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

Issue 766154 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Sep 30
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug



Sign in to add a comment

Monaco.dfont breaks text height calculations (Linux)

Reported by grawity@gmail.com, Sep 18 2017

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.91 Safari/537.36

Example URL:
data:text/html,<style>b,tt{background:orange;padding:2px;font-family:Monaco,Arial,monospace}</style><p>foo<b>bar</b><tt>baz</tt>quux</p>

Steps to reproduce the problem:
1. Use Linux.
2. Have the Monaco font (in .dfont format) installed.
3. Have Chromium 61 or Google Chrome 61.
4. Open a page which uses Monaco somewhere.

What is the expected behavior?
The elements should look like in other browsers.

What went wrong?
The elements seem to be 0 pixels tall (not counting padding). The text itself isn't clipped, but the background and the clickable area *are*.

Does it occur on multiple sites: Yes

Is it a problem with a plugin? No 

Did this work before? Yes 60.x

Does this work in other browsers? Yes

Chrome version: 61.0.3163.91  Channel: stable
OS Version: 
Flash Version: Shockwave Flash 27.0 r0

I found Monaco.dfont on GitHub. I'm not sure which macOS version it's from; will try to find a newer one. Regardless, it's still a bug compared to v60.
 
Screenshot from 2017-09-18 15-10-42.png
74.7 KB View Download
Components: -Blink Blink>Fonts

Comment 2 by grawity@gmail.com, Sep 19 2017

(Oh, and as you can see from the screenshot, the affected text is using the 2nd font – perhaps Chrome is thinking that Monaco is a completely empty font?)
Cc: sc00335...@techmahindra.com
Labels: Needs-Triage-M61 Needs-Feedback Triaged-ET
Unable to reproduce the issue on 61.0.3163.91 and on latest dev 63.0.3218.0 using Ubuntu 14.04 with below steps.

1.Cloned monaco font from https://github.com/todylu/monaco.ttf
2.Launched chrome and typed data:text/html,<style>b,tt{background:orange;padding:2px;font-family:Monaco,Arial,monospace}</style><p>foo<b>bar</b><tt>baz</tt>quux</p>
 in omnibox.
3.Text is seen clearly without any breakage. Attaching screenshot for reference. 

NOTE: Same behaviour is seen in Firefox and M50 of chrome.

@Reporter: Could you please provide actual monaco .dfont to be added? and could you also please check in fresh profile which don't have any apps and extensions added.

Thanks!
Issue 766154.png
151 KB View Download

Comment 4 by grawity@gmail.com, Sep 21 2017

The font I use is from:
https://github.com/vjpr/monaco-bold/raw/master/Monaco.dfont

(The repository's README claims it is unaltered from OS X.)

Can still reproduce on empty profiles, with the official binary builds of Chrome Stable 61.0 and Dev 63.0 (i.e. not limited to Arch's chromium).
Project Member

Comment 5 by sheriffbot@chromium.org, Sep 21 2017

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "sc00335628@techmahindra.com" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 6 by grawity@gmail.com, Sep 21 2017

Can also reproduce on an empty user account, after copying Monaco.dfont to ~/.local/share/fonts/ (the format is supported directly – no conversion to TTF needed).

It *could* be a combination of Chrome 61 and the library versions that's triggering this. Arch has freetype 2.8, harfbuzz 1.5.1, pango 1.40.12 … not sure what else is involved.

Comment 7 by e...@chromium.org, Sep 23 2017

Cc: drott@chromium.org derat@chromium.org

Comment 8 by apodt...@gmail.com, Sep 26 2017

Do you have FT_CONFIG_OPTION_MAC_FONTS enabled on the bundled FreeType? What about system FreeType? Your system might think that Monaco is available, while Chromium cannot open it. Whatever is shown is not Monaco btw.

Comment 9 by e...@chromium.org, Sep 27 2017

Labels: Needs-Feedback

Comment 10 by grawity@gmail.com, Sep 27 2017

> Do you have FT_CONFIG_OPTION_MAC_FONTS enabled on the bundled FreeType?

I'm not 100% sure where to look, but Arch does not customize the bundled freetype – it's exactly whatever Chromium includes...

Is that in 'third_party/freetype/include/freetype-custom-config/ftoption.h'? I see that file does not have _MAC_FONTS defined.

> What about system FreeType?

It's enabled in system FreeType, yes.

> Your system might think that Monaco is available, while Chromium cannot open it.

I see, I'll have to ask the Arch packager to enable this option in Chromium, then.

Though, I still feel that Chromium should be ignoring unsupported fonts entirely, and not pretending they're 0×0-sized...
Project Member

Comment 11 by sheriffbot@chromium.org, Sep 27 2017

Cc: e...@chromium.org
Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "eae@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 12 by e...@chromium.org, Sep 28 2017

Status: Available (was: Unconfirmed)
Project Member

Comment 13 by sheriffbot@chromium.org, Sep 28

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Status: WontFix (was: Untriaged)
No longer able to reproduce.

Sign in to add a comment