FYI this doesn't repro on ChromeOS or Linux. I don't have a Windows machine to test it on, and it may be Windows specific.

FYI, I am able to reproduce this on Windows, see screenshot.

Deleted: japanese_fonts_custom.png 57.4 KB

	japanese_fonts_custom.png 57.4 KB View Download

Ah, the screen shot from dpapad@ helped me realize that I can repro this on Linux. I'll take this bug.

It happens in Options too.

On Linux, the font names being searched for are:
"VL Gothic"
"Sazanami Mincho"
"VL Gothic"
"VL Gothic"
I think these values come from this file:
chrome/app/resources/platform_locale_settings/locale_settings_linux_ja.xtb
None of those are in the fonts list (i.e. they are not installed). The label "Custom" (or the translation thereof) is used when the specific pref value is not present in the dropdown list. 


The font beginning with a comma is specified in:
chrome/app/resources/platform_locale_settings/locale_settings_win_ja.xtb
<translation id="IDS_SANS_SERIF_FONT_FAMILY">,Meiryo,Yu Gothic</translation>
I suspect (but haven't proven) that a leading comma signifies a comma separated list (since empirically, entries with a list start with a comma and entries that are a single name do not start with a comma).


The code is working as intended, but it's possible that what was intended is not excellent (and we want excellent). What would be closer to excellent? 
 - We could show the font name as the selected value even if it's 
   not a valid value (i.e. add "Sazanami Mincho" to the font list 
   and say "Sazanami Mincho" is selected - even though that is  
   meaningless since "Sazanami Mincho" is not installed - 
   problem: it's misleading). 
 - Web ui is restricted in what can be shown in a select drop down, 
   so styling the selection may be intractable. (Problem: we may not
   be able to use styling to show that the value is special)
 - We could suffix the faux entry ("Sazanami Mincho") with "not installed" 
   or similar (problem: the label can get rather long)
 - We could try to find out what font is being used instead of the
   intended font (i.e. since text is showing up and "Sazanami Mincho"
   is not installed, we must be defaulting to something else). 
   (Problem: it's misleading; and if "Sazanami Mincho" were installed
   the font may unexpectedly change even though we had said that
   font X was selected (because it wasn't really)).
 - Find out what font we are defaulting to and then change the 
   actual preference to be that default font. (Problem: changing
   setting values without the user|admin|vendor making that choice).

How likely is it that someone using ja will *not* have those fonts installed (I don't because I don't have Japanese OS options installed)

I see now that leading comma may be the real issue. Which needs some investigation on whether having a comma separated font selection is a valid pref choice.

Are Meiryo or Yu Gothic installed on a Japanese Windows machine?

Notes:

The comma separated list of font names was added in:
https://codereview.chromium.org/2454583002

Support for having comma separated font name lists was added in:
https://codereview.chromium.org/2441343003/

Use of that code was added to old options in 2016 (but not to md settings) in:
https://codereview.chromium.org/2441343003

Porting that to MD settings should help with the comma separate font list (but not the case when there is no matching font installed). 

kojii@ does porting the comma separated fonts list to chrome/browser/ui/webui/settings/* sound reasonable? If so, I think you'd want to copy the files over from chrome/browser/ui/webui/options/ because .../options/ is destined to be removed from the code.