This affects the GitLab award emoji menu which is being tracked in https://gitlab.com/gitlab-org/gitlab-ce/issues/37654

Able to reproduce on Windows-10 and Mac OS 10.12.6 using chrome stable M61-61.0.3163.79 
Note: Observing square box instead of emoji in Ubunt 14.04

Bisect Information:
=====================
Good build: 60.0.3099.0 (471588)
Bad Build : 60.0.3100.0 (471639)

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/dbbb4e564b1412421f3a7b70cd8fa267581b3dea..d688239189bd18103150f9135931cc632ec3d308

From the above change log suspecting below change
https://chromium.googlesource.com/chromium/src/+/ee36babf91a54379889370cdd207e818555acb5d

jshin@- Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Will check ICU line break iterator (because the range in comment 4 include ICU update to 59.1). 

Hmm  on Linux, I even have U+1F91D (heart) + U+1F3FF (a skin tone modifier).  

A test program is attached and the result is unexpected and wrong. I'll file an upstream bug. (it's really strange because this must have been tested by both ICU and Blink .) 

iteration=0, index=0, ruleStatus=0
iteration=1, index=2, ruleStatus=0
iteration=2, index=4, ruleStatus=0
iteration=3, index=6, ruleStatus=0
iteration=4, index=8, ruleStatus=0
iteration=5, index=10, ruleStatus=0
iteration=6, index=12, ruleStatus=0
iteration=7, index=12, ruleStatus=0
iteration=8, index=12, ruleStatus=0
iteration=9, index=12, ruleStatus=0
iteration=10, index=12, ruleStatus=0
iteration=11, index=12, ruleStatus=0

Deleted: emojilb.cpp 635 bytes

emojilb.cpp 635 bytes View Download

Filed http://bugs.icu-project.org/trac/ticket/13452  

Hmmm... It turned out that 

U+1F91D has LB=Ideographic instead of LB=E_Base (see 
https://unicode.org/cldr/utility/character.jsp?a=1F91D  ). 

So does U+1F93C . 

The current ICU behavior is compliant to UAX #14 ( http://unicode.org/reports/tr14/ ). 

OTOH, most users have a different expectation. Handshake and wrestler Emoji seem quite natural to be skin-tone-modified (except that Handshake has two hands .... ). It appears that there are already Emoji fonts that apply skin-tone-modifier to those Emoji. 

Anyway, some spec consideration is necessary.  

Andy and Mark: what's your take on this? 

I meant to check this on Safari + macOS 10.13 at home last night, but I forgot. I suspect that Safari (when tested by the reporter) didn't have the most up-to-date Unicode Emoji / Line-breaking data. With that in place, I believe Safari will behave like Chrome. 

For now, closing as WAI. I'll talk to Mark and Andy about this offline. 

It turned out that Unicode Emoji data had changed over time. 

Wreslters and Handshakes used to be classified as Emoji_Base, but not any more. That's why the behavior changed when I upgraded ICU to 59.x 

@js... Can you link to the files in the source or even the specific change (I am curious)? Perhaps even some discussion/review that happened around this, linking to the spec, etc.

I can understand changing the classification of characters causing it to be separate but not why it only happens when width constrained???

With Chrome 61.0.3163.100, I can only reproduce the width constrained differences with the skin toned handshake emoji "🤝🏿". The wrestlers emoji is always two characters now.

---

I also noticed the linked jsFiddle in the OP no longer is working. It looks like jsFiddle is messing up the unicode. I created a CodePen if you want to easily view it, https://codepen.io/MadLittleMods/pen/dZMeXN