Rocket.chat: Emoticons don't display properly, if there are multiples one

[carlspring]

Description:

In the web-chat, emoticons require need to be separated by spaces on both sides.

Steps to reproduce:

For example it will only show the middle one, if you enter the text below:

:D :D :D 

Expected behavior:

Three emoticons are supposed to be displayed, when entering:

:D :D :D

Actual behavior:

Workaround

Add spaces before and after each emoticon, like this " :D :D :D ".

Obviously, this is not quite convenient. It should be able to parse this correctly.

Server Setup Information:

• Version of Rocket.Chat Server:
• Operating System: Linux
  0.69.1
• Deployment Method:
• Number of Running Instances:
• DB Replicaset Oplog:
• NodeJS Version:
• MongoDB Version:

[steve-todorov]

This also happens if the message contains only an emoticon like :D - you need to have white space like so :D, otherwise it displays just as text instead of an icon. I think this is not only scoped to the webchat - I am using the deb package and this happens there as well.

[localguru]

I can't confirm this under 0.69.2 and on open.rocket.chat (0.70.3) in the electron client (2.14.0) and in the browser (FF 62.0.3 (64-bit)). Have you tested it on open.rocket.chat?

It's interesting that the Android client, with ":D" or " :D " does not generate any smilys at all.

[steve-todorov]

I've just tried it with the latest docker image which is tagged as 0.70.4 - same issue. Screenshot from using the web browser (but the absolute same thing happens with the client, which is 2.13.3. It only works if you add spaces around ":D" so that it is " :D ". I don't see the client version 2.14 to have been released on the website?

Also, I've tried Rocket.Chat and Rocket.ChatNG on Android. The NG version is correctly replacing the :D string with an icon, but only in the app - if you open the message from a browser or the desktop client it's still :D instead of emoji. The Rocket.Chat app doesn't replace anything - it just shows :D.

[localguru]

For Android App see also https://github.com/RocketChat/Rocket.Chat.Android/issues/1755

[reetp]

Electron is here:
https://github.com/RocketChat/Rocket.Chat.Electron/releases/tag/2.14.0

Just tested on https://open.rocket.chat #general with Chromium on Xubunut and is is fine

I don't believe this is an issue with Rocket, but possibly with the client. However, we don't know what OS or client is being used.

Can you please provide further information.

[carlspring]

Hi,

I'm using it through a web browser in Chrome Version 63.0.3239.108 (Official Build) (64-bit) for Linux. The RocketChat server is now running 0.70.4 and the issue is still there. I've also tried the client from rocketchat-2.13.3.x86_64.rpm. Same issue.

[steve-todorov]

@reetp thanks for the link! I've updated the client and the issue is still present under Ubuntu 18.04. It's also present in the Chrome/Firefox browsers (again under the same OS).

[reetp]

Can you check/test here https://open.rocket.chat/
I still think this is a client rather than server issue but not sure of the best place to put it.

[carlspring]

This is interesting. It works fine there.

So, what's the difference? Like I said, the "client" is my Chrome web browser.

[steve-todorov]

I've just tried it and it works for me as well in the client (2.14.0). Not very sure why it's working differently?

[reetp]

Hmmm - but surprised by your Chrome version.

I am running this:
Version 65.0.3325.181 (Official Build) Built on Ubuntu , running on Ubuntu 14.04 (64-bit)

Note also the latest client is here:
https://github.com/RocketChat/Rocket.Chat.Electron/releases/tag/2.14.0

However, it doesn't explain why it works with open.rocket.chat and not your own server.
I have also tested on my version (docker, 0.70.4) and have no issues with it.

Probably need to have a look in your rocketchat logs and see what is being sent.

Meteor ➔ method sendMessage -> userId: gsadk424Rbw23B2BC , arguments: [ { _id: 'NctYAadoEfh5ydpyK',
rid: 'DvHsTdv9uCixHCGvu',
msg: ':D :D' } ]

That renders on my own system.

[steve-todorov]

Log seems to be similar to yours. Is there any specific setting I need to configure in the admin settings?

I20181017-13:26:01.572(0) Meteor ➔ method getRoomNameById -> userId: rocket.cat , arguments:  [ 'W4WnMiRTQ6MrdJ4qb' ] 
I20181017-13:26:47.582(0) Meteor ➔ method stream-notify-room -> userId: ioxLBnQoiXD9FFZcF , arguments:  [ 'W4WnMiRTQ6MrdJ4qb/typing', 'steve.todorov', true ] 
I20181017-13:26:53.762(0) Meteor ➔ method stream-notify-room -> userId: ioxLBnQoiXD9FFZcF , arguments:  [ 'W4WnMiRTQ6MrdJ4qb/typing', 'steve.todorov', false ] 
I20181017-13:26:53.783(0) Meteor ➔ method sendMessage -> userId: ioxLBnQoiXD9FFZcF , arguments:  [ { _id: 'mcpqHXpAARZJ2SXsH', rid: 'W4WnMiRTQ6MrdJ4qb', msg: ':D' } ] 
I20181017-13:26:53.788(0) Meteor ➔ method canAccessRoom -> userId: ioxLBnQoiXD9FFZcF , arguments:  [ 'W4WnMiRTQ6MrdJ4qb', 'ioxLBnQoiXD9FFZcF' ] 
I20181017-13:26:53.854(0) Meteor ➔ method canAccessRoom -> userId: null , arguments:  [ 'W4WnMiRTQ6MrdJ4qb', 'rocket.cat' ] 
I20181017-13:26:53.933(0) Integrations ➔ Outgoing WebHook.debug Execute Trigger: sendMessage 
I20181017-13:26:53.936(0) Integrations ➔ Outgoing WebHook.debug Got the event arguments for the event: sendMessage { event: 'sendMessage',   message:     { _id: 'mcpqHXpAARZJ2SXsH',      rid: 'W4WnMiRTQ6MrdJ4qb',      msg: ':D',      ts: 2018-10-17T13:26:53.784Z,      u:        { _id: 'ioxLBnQoiXD9FFZcF',         username: 'steve.todorov',         name: 'Steve Todorov' },      unread: true,      _updatedAt: 2018-10-17T13:26:53.843Z,      editedBy: undefined,      editedAt: undefined,      emoji: undefined,      avatar: undefined,      alias: undefined,      customFields: undefined,      groupable: undefined,      attachments: undefined,      reactions: undefined,      mentions: [],      channels: [],      sandstormSessionId: null },   room:     { _id: 'W4WnMiRTQ6MrdJ4qb',      name: 'test2',      fname: 'test2',      t: 'p',      msgs: 71,      usersCount: 2,      u: { _id: 'ioxLBnQoiXD9FFZcF', username: 'steve.todorov' },      customFields: {},      broadcast: false,      ts: 2018-09-25T02:21:52.464Z,      ro: false,      sysMes: true,      members: null,      default: false,      _updatedAt: 2018-10-17T13:26:01.440Z,      lm: 2018-10-17T13:26:01.310Z,      lastMessage:        { _id: 'ceCzZHbRfyrNiYwNf',         rid: 'W4WnMiRTQ6MrdJ4qb',         msg: ':D',         ts: 2018-10-17T13:26:01.310Z,         u: [Object],         unread: true,         _updatedAt: 2018-10-17T13:26:01.378Z,         editedBy: null,         editedAt: null,         emoji: null,         avatar: null,         alias: null,         customFields: null,         groupable: null,         attachments: null,         reactions: null,         mentions: [],         channels: [],         sandstormSessionId: null },      username: 'steve.todorov' } } 
I20181017-13:26:53.938(0) Integrations ➔ Outgoing WebHook.debug Starting search for triggers for the room: W4WnMiRTQ6MrdJ4qb 
I20181017-13:26:53.940(0) Integrations ➔ Outgoing WebHook.debug Found 0 to iterate over and see if the match the event. 

[reetp]

Hmmm. Leaves me stumped !!
Rocket server doesn't seem to be throwing an error. Works on open.rocket.chat.
Corrupted icons/custom icon shorcuts?
What happens if you select an emoticon from graphical selector rather than by typing?

[steve-todorov]

I don't know where to check for custom icon shortcuts, but we definitely don't have any custom icons setup. Icons display properly only if they contain two colons - in the beginning and in the end. For example, if you write :joy: it displays just fine, but if it's :D (instead of :grinning:) and :X (instead of :no_mouth:) it won't display unless there is whitespace like so => :D <=

[reetp]

OK, I just tested this again with Chromium on 0.74.2

:D:D:D fails and shows exactly that

:D :D :D with spaces between works (doesn't need a leading space)

Presumably this is a parsing issue, but not sure how you would fix it, and whether it would affect other things

[steve-todorov]

I'm not sure, but it looks like a client side issue? Maybe the regex which is matching this has a bug?

[tassoevan]

:D:D:D fails and shows exactly that
This is by design, to avoid parsing amongst words.

I've found the root cause: the markdown parser. If you selected Marked instead of Original, it conflicts with the emoji parser.

[steve-todorov]

@tassoevan I confirm - I just tried switching from Marked to Original and emojis work.

[carlspring]

Yeah, but as programmers, we need to be able to use Markdown in our chats. Is there a way to get this to work for both? I mean -- emojis are not the end of the world, but it would be great to have this working! :)

[tassoevan]

@carlspring Sure, and, honestly, I don't think we need competing markdown parsers here. We're aware of other issues in the message rendering architecture too and I believe that soon we'll raise the ultimate discussion to tackle them.

[steve-todorov]

Hi,

Is there any progress on this issue? I've just upgraded to 1.1.1 and now it's even worse. The following doesn't work anymore: my text :D. Previously when you added whitespace after :D it would work as expected. Now that's not working at all. The only way an emoji is rendered is if it's wrapped in between text.

[ggazzo]

please any problem reopen