Interestingly emoji also seem to break this bug tracker, which is why my description above is incomplete. Here’s the rest of my description (since I can’t seem to edit my original description).

---

What is the expected result?
I see a colorful emoji.

What happens instead?
I see a boring black & white emoji

Please provide any additional information below. Attach a screenshot if
possible.

To make an emoji look good in Chrome for Windows I have to explicitly set the font-family of the emoji containing HTML element to "Segoe UI Emoji", which is unintuitive, and a nuisance.

On OS X (or macOS, or whatever) zero browsers require an explicit font-family assignment. On Windows Chrome and Edge require the assignment, but Firefox does not.

I wrote up a blog post that gives specific screenshots that might be more clear than the description in this ticket: https://www.tjvantoll.com/2016/06/15/emoji-on-windows/.

My request is to have Chrome automatically detect the unicode for emoji and automatically assign the “Segoe UI Emoji” font family. I submitted the same request for Edge here https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/7900499/.

Thanks!

Actually I misspoke a bit. In Edge you can get colorful emoji by assigning `font-family: "Segoe UI Emoji"`, but in Chrome for Windows I cannot get colorful emoji regardless of the technique that I use.

 Issue 459056  and related code should ensure that the emoji font is used for emoji when appropriate, while  issue 333011  implements support for rendering color emoji in content (currently in canary/dev, and will go to beta/stable in M53). So, explicitly setting the emoji font family definitely should not be needed. If you are finding that it is still needed, please include a repro: ideally as a self-contained html file, or as a link if that is not possible.

 Issue 617376  deals with color emoji in Chrome UI (tabstrip, bookmark bar, url bar, etc) so I don't think that's what this bug is talking about.

I should also note that color emoji are only supported on Win8.1 and later. If you are testing on Win7 it is expected that all emoji render only in B/W.

Just to note I checked and emoji look great in Canary even without an explicit font assignment, so I'm all set here.

Thanks for all your work on this; it's much appreciated. I would include an emoji to show my gratification except it seems to break this bug tracker, which I find somewhat ironic. Anyways, have a good one!

Thanks for checking and letting us know.

Is there a way to get this working when running with the `--no-sandbox` flag? It looks like it still shows box characters for the test page when Chrome is run with this option.

https://cs.chromium.org/chromium/src/content/renderer/renderer_main_platform_delegate_win.cc?l=56

Deleted: Screen Shot 2016-10-04 at 3.57.32 PM.png 17.1 KB

	Screen Shot 2016-10-04 at 3.57.32 PM.png 17.1 KB View Download

#9: quick test indicates it should just be a matter of moving the initialize call outside the if-block. I'm curious though if there's a particular reason why you are running with the --no-sandbox flag?

#10: I'm trying to enable support for this in Electron which runs renderer processes with `--no-sandbox`, https://github.com/electron/electron/issues/7334

Is there any danger in calling InitializeDWriteFontProxy with no sandbox? I wasn't sure why this was originally behind the sandbox option check.

We could patch our version of chromium to move that call outside the if block if it is safe to do.

Thanks for replying.

Created https://codereview.chromium.org/2387373003/ for the fix. Please open a new bug and assign to me so we can track it.

Opened https://bugs.chromium.org/p/chromium/issues/detail?id=652898, I'm not sure I'm able to assign it directly to you though, thanks for the quick fix.