Native Unicode Emojis
What does this MR do?
Previous MR, !9437 (closed)
- 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
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, #27977 (closed) but I'd rather put that into another MR.
Also interesting that running our custom element logic on each
gl-emojielement seems to make the DOM faster. A bit counter-intuitive but is what I found when profiling.
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
- Disable markdown caching by applying this diff patch, https://gitlab.com/snippets/1622055
git apply gitlab-disable-markdown-caching.diff
bundle exec rake gemojione:digeststo generate the new
- Is it okay to have the native emojis be sized to the font-size of the current context instead of always 20px?
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
- 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)
- Clear out the cache (purge)
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.
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
Why was this MR needed?
Screenshots (if relevant)
Immediate feedback from first click (freshly loaded page):
Does this MR meet the acceptance criteria?
- Changelog entry added
- Documentation created/updated
- Added for this feature/bug
- All builds are passing
- Conform by the merge request performance guides
- Conform by the style guides
Branch has no merge conflicts with
master(if it does - rebase it please)
- Squashed related commits together
- EE branch
Possibly rspec tests for falling back emojis
- Will need a way to programmatically define the emoji support map
- Fix up a bit more of the jank
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