Inconsistent Emoji when sans-serif is Noto Sans CJK/Source Han Sans

Bug report:

• Operating system and version: All system in concept, especially Linux distros that with Chinese support
• Browser and version: All browsers that can set font for sans-serif
• Reduced test case: https://jsbin.com/gobared/

Steps:

1. Set browser default sans-serif to Noto Sans CJK/Source Han Sans, which is commonly used as Chinese/Japanese/Korean font in Linux distros.
2. Open a site with Emoji that built with Bootstrap

Screenshot:

Suggested fix: Put Emoji fonts in front of text fonts like

$font-family-sans-serif:
  // Safari for OS X and iOS (San Francisco)
  -apple-system,
  // Chrome < 56 for OS X (San Francisco)
  BlinkMacSystemFont,
  // Emoji fonts
  "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji",
  // Windows
  "Segoe UI",
  // Android
  "Roboto",
  // Basic web fallback
  "Helvetica Neue", Arial, "Noto Sans"
  , sans-serif !default;

[patrickhlauke]

@XhmikosR i think this is slightly different aspect. #31960 warns about unicode chars being replaced by emoji that then can’t be styled colour-wise, while this issue highlights that in some cases the emoji fonts are not kicking in, if i understand it correctly … i.e. the opposite issue of what #31960 describes.

would reshuffling the order in which the fonts are called have any other adverse effects? if not, i’d say go for the suggested fix here (though to clarify, i assume this is just about moving the emoji fonts and not duplicating it like in the above code block?)

[ffoodd]

Agreed, and even in that case it’d only need some font-family love for this specific situation. I’d say: let’s try simply moving sans-serif after emoji fonts.