is this chromeos-only?

not reproducing on Linux

do you have an console errors?

not seen console error, see the screenshot

Deleted: Screenshot 2016-08-04 at 4.28.00 PM.png 308 KB

	Screenshot 2016-08-04 at 4.28.00 PM.png 308 KB View Download

not able to reproduce on fake CrOS

Deleted: 2016-08-04-164523_995x979_scrot.png 125 KB

	2016-08-04-164523_995x979_scrot.png 125 KB View Download

Issue reproduced on minnie, peppy as well 8673.0.0/ 54.0.2817.0

don't have those devices (well, I'm not sure all of your guys' code names, so maybe I do but I'm unsure), so it'd be hard for me to fix

I can repro this on a Pixel 2.

No clue why / how this would have regressed, unless maybe we changed the fonts for Chrome OS recently?

Side effect of  bug 617281  maybe?

silly question: are the fonts available in chrome://md-settings/fonts when this happens?

"Update chromeos font install script" -- that does sound suspicious. maybe something got out of sync?

https://codereview.chromium.org/2043883004

No, fonts are not available in chrome://md-settings/fonts when this happens. (54.0.2817.0 quawks).

Wild theory: This looks related to switching Chrome OS to gn.

The font list comes from pango. But apparently pango is disabled when ozone is enabled.[1]

use_pango = false means we'd build with font_list_ozone.cc[2]  which returns an empty list in GetFontList_SlowBlocking().

Seems like the intent is to disable pango on Linux Ozone builds, but that affects Chrome OS as well. Should
    (is_linux && !use_ozone)
be something like
    (is_linux && (is_chromeos || !use_ozone))
?

I've confirmed that hardcoding use_pango = true (it's not a standalone gn argument) restores the font lists in Settings/Options.

[1] https://cs.chromium.org/chromium/src/build/config/ui.gni?q=use_pango+use_ozone&sq=package:chromium&dr=C&l=85
[2] https://cs.chromium.org/chromium/src/content/common/font_list_ozone.cc

To dpranke@ to assess gn theory for use_pango. I don't know if this is still related to toolkit_views (from the original  issue 313793 , e.g. would it matter if is_chromecast which disables toolkit_views).

Looks like this might be a question for reveman@, since this was changed in 

https://codereview.chromium.org/1415153007

Is there a dependency from pango or cairo on glib?

That change was only to allow a developer to optionally do a non-ozone build without using glib. We don't need that anymore as Ash without doing a chromeos build is no longer supported. The change shouldn't effect the default build behavior. Feel free to revert it if needed.

FYI, in  issue 630508  I am planning to move the implementation to fontconfig.

bouncing this back to michaelpg@ to fix the use_pango/glib setting, since it looks okay to do so.

hmm, after  issue 630508 , I'm not sure how to test this change.

Any update on this bug? I can still reproduce in latest M54 (samus)

It appears to be fixed in M55 (on my quawks machine).

I thought https://codereview.chromium.org/2278143002 made it into 54. That was revision 414677 but we branched at 414607.

dpranke: are the beta and stable built with gn already (not gyp)?

I'm kinda nervous to change gn settings a week before stable.... drott@ would it make sense to try to merge your CL into the beta, or is it too risky of a change?

Er, hshi@ apparently merged that change into 2840 4 hours ago: https://codereview.chromium.org/2406983002

Haixia, was that done to fix this issue (or was it unrelated)? If so, were you able to confirm the fix?

Re:#24 I am not aware of this bug ("Settings->Fonts dropdown are empty list).

That CL was intended for bug https://bugs.chromium.org/p/chromium/issues/detail?id=635030 (Flash regression issue). However the original CL description did not properly mention the bug number.

Stable is currently M53 (branch 2785), which on ChromeOS still used= GYP. Beta is M54 (branch 2840), which is GN.

Is https://codereview.chromium.org/2406983002 expected to impact this issue (fix it)?

Re #23, I believe it's safe to merge to Beta, especially since it would impact this issue and I believe it fixes it, even though I have no means of reproducing the state before.

> That CL was intended for bug https://bugs.chromium.org/p/chromium/issues/detail?id=635030 (Flash regression issue). However the original CL description did not properly mention the bug number.

The CL was actually intended for the bugs  630508 ,  457307  but seems to have fixed the Flash regression issue, even though it's unclear to me why. I've asked for an analysis in that issue, https://bugs.chromium.org/p/chromium/issues/detail?id=635030#c20

OK. Could someone please test last night's M54 beta on an ozone device? https://goto.google.com/sojwy

Per #24 and #26, this should be a gn build with the suspected fix included. The previous night's beta should have this bug; last night's beta should be fixed.

To abodenha to manage while CrOS settings folks are OOO.

If I'm reading this thread correctly, the needed change HAS been merged to 54 we just need to make sure it actually fixes the bug as we expect.

dhaddock@ can someone on your team take a look?

Not reproduced on ChromeOS:8743.62.0/Chrome:54.0.2840.58 Samus.

Marking as verified as per the comment#30.

[Auto-generated comment by a script] We noticed that this issue is targeted for M-54; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-54 label, otherwise remove Merge-TBD label. Thanks.