Able to reproduce the issue on reported chrome version #70.0.3538.102, latest stable #70.0.3538.110 and latest chrome #72.0.3622.0 using Ubuntu 17.10, Windows 7 and Mac OS 10.12.6. Observed that after navigating to "https://www.youtube.com/watch?v=gAirINwjaxE" under the comment section the emojis are not as Noto color emoji.
Note: Issue is not seen on Windows 10.

The behavior is seen from old M-60 builds(#60.0.3112.78). This is a non-regression issue, hence marking it as untriaged and requesting someone from the dev team to look into the issue.
Thanks.!

I post here the bugs for Firefox and WebkitGTK:
https://bugzilla.mozilla.org/show_bug.cgi?id=1509988
https://bugs.webkit.org/show_bug.cgi?id=191976 -> This contains more information and suggestions from fontconfig upstream to try to solve the issue, maybe it could help here too

Thanks

The website specifies "font-family: Roboto, Arial, sans-serif;" which requires all characters that is supported by any of those fonts to use that specific font. 

This is working as intended as far as I can tell. drott?

Well, ideally it should try to use the color emojis from Noto Color Emoji font set instead of using the ugly B&W emojis from Dejavu and falling back to Color Emoji for the characters still not supported, leading to that mix of emojis with different style 

pachoramos@gmail.com, using codepen.io, jsbin.com or similar, can you please create a test page with the same font-stack, i.e. the same list of fonts in the font-family: CSS style rule as on the pages that you find these problems? 

As you said: If you look at the styles panel in Firefox and DejaVu Sans has coverage for some of the emoji, then it is correct to use these glyphs from the Deja Vu sans, if the font-family style contains: sans-serif - as sans-serif is usually mapped to DejaVu Sans on Linux.

If no glyph coverage is found in the font-family listed fonts, then we attempt fallback. Currently, we do that by asking FontConfig for a font that contains the U+1F46A FAMILY emoji. This detection will change at some point to use the generic FontConfig family "emoji".

From Chrome's perspective, I currently not see any issue: The pages should either provide an emoji web font, or provide the generic font name "emoji" higher in their font stack, or perhaps DejaVu Sans should not contain any emoji glyphs, or the pages should use VS-16 with their emoji to express that they prefer color presentation.

I understand that from the users' perspective this is all less than ideal, but I am not quite sure how we can help here.

In the comments of:
https://bugs.webkit.org/show_bug.cgi?id=191976

you can see some suggestions about how to handle this issue on browsers side from fontconfig upstream perspective (Akira TAGOH comments in that bug report), maybe that could help