Skip to content

Native Unicode Emojis

Eric Eastwood requested to merge 26371-native-emojis-v3-code into 26371-native-emojis-v3

What does this MR do?

Previous MR, https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9437

  • Use native emoji's if platform supports them. Fallback to images or CSS sprites
  • Emoji's are now client-side and do not require another ajax request
    • See autocomplete (typeahead)
    • See award emoji menu
  • Improve award emoji menu performance
    • Pre-build emoji menu on button hover/focus
    • Only pre-build the first category of emoji's to avoid jank and quick initial display if necessary
    • Load in remaining emoji's sequentially in a requestAnimationFrame after actually opening the menu (we do it after the menu expand transition to avoid jank)
    • Adjust the emoji menu CSS transition bezier curve so that it doesn't dip negative(zero) and give a perceptive delay
  • Add alias lookup in award emoji menu

For the unicode support testing:

We only do the canvas check on page-load for each entry in the test map(18 entries, small handful) which are batched into one write and cache the results for future page loads (localStorage). This cache is only invalidated on browser version change.

The thing we don't cache is comparing an emoji name to the test logic. We first check the cached-support-map for unicode version support, then the special cases. If wanting to cache the logic results, this map could have up to 1791 entries in it (invalided on browser version). That kind of map seems too large and I don't think this is the cause for jank. The results would trickle into the map as the user encountered new emojis.

The DOM handling the 1000's of elements is what is causing issues. We already place each category one by one into the DOM which helps a lot but these could be split up further to help things as it still causes long frames. Another solution is moving to category tabbed based picker, https://gitlab.com/gitlab-org/gitlab-ce/issues/27977 but I'd rather put that into another MR.

Also interesting that running our custom element logic on each gl-emoji element seems to make the DOM faster. A bit counter-intuitive but is what I found when profiling.

@MadLittleMods, https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9437#note_24287084

Are there points in the code the reviewer needs to double check?

Quick tip: If you are looking for an emoji that will fallback on macOS Sierra(10.12), :rofl: is unicode 9.0 and will fallback

Dealing with legacy markdown caching

  • We will need to figure out how best to deal with the cached markdown in production
    • Clear out the cache (purge)
      • Pro: Clean break from legacy emojis
      • Con: How do we do this for self installations? Part of migration? 9.0 breaking change?
      • Con: Extra CPU to regenerate everything as users trickle onto things
    • Add a post-processor to change the img.emoji-icon
      • Con: This processor will have to live in the codebase forever(until we want to give up trying to fix legacy image emojis)
      • Con: Extra CPU for every request
      • Pro: We possibly need a post-processor anyway in the future if we want to server-side render emoji fallbacks, see https://gitlab.slack.com/archives/development/p1486577609004641
    • Just ignore it and all new cached things will be native emoji's
      • Pro: No further action needed
      • Con: Older posts use image based emoji's forever 😢 (inconsistent across site)

To add some more info on size, the unminified digests.json is 324KB currently. When added to minified(prod) application.json, we grow from 724KB to 1MB. When serving a gzipped, minified(prod) application.json, we grow from 211KB to 313KB

Previously, we would pull down 511KB of HTML when you try to add an emoji.

Outdated application.js size increase breakdown, https://gitlab.com/snippets/1638294

We can split into manageable MRs if necessary. Here is the MR/branch dependency tree/graph I made when I though I was going to have to split it up, see https://drive.google.com/file/d/0B4cjIdQwaPXhZzRUd05GWGNTbG8/view?usp=sharing

-> http://i.imgur.com/44CfjCJ.png

Why was this MR needed?

See

Screenshots (if relevant)

Immediate feedback from first click (freshly loaded page):

Does this MR meet the acceptance criteria?

Todo

Cross-browser Testing

I checked these browsers during development but need to do another pass

  • macOS Chrome
  • macOS Firefox
  • macOS Safari
  • Windows 10 Chrome 55-57
  • Windows 10 Firefox
  • Windows 10 IE11
  • Windows 10 Edge
  • Windows 8.1 Chrome
  • Windows 8.1 Firefox
  • Windows 8.1 IE 11
  • Windows 7 Chrome
  • Windows 7 Firefox
  • iOS simulator 9.3 (mobile-safari)
  • Android 5 Chrome
  • Android 6 Chrome
  • Android 7 Chrome
  • Android 6 Firefox
  • Android 7 Firefox
  • Ubuntu 14.04 Chrome
  • Ubuntu 14.04 Firefox
  • Ubuntu 16.04 Chrome
  • Ubuntu 16.04 Firefox

What are the relevant issue numbers?

Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/26520 Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/27250 Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/22474 Closes #26371 (closed)

Merge request reports