Emoji falsely included in URL in push notification preview when URL contains `:emoji_name:` identifier somewhere
Reproduction
- Person A sends this message to person B:
https://example.com/:x:/somethingin real life I encountered this in:https://companyname-my.sharepoint.com/:x:/g/personal/username_companyname/XXX?e=ZZZ - Person B gets a push notification.
Expected
- In the push notification preview the URL is shown as-is (as it was sent).
- A URL and also an
inline code snippetshall be exempt from any on the fly text replacements / transformations.
Actual
In the push notification preview the URL includes an Emoji Unicode symbol instead of the emoji identifier markup.
Check out: https://example.com/❌/something
| macOS | Windows |
|---|---|
Additional context
- Occurs on RocketChat Desktop app for: macOS as well as Windows.
- So I assume this bug happens server-side (text preview snippet processed before sent to push notification service)
Client Setup Information
- Desktop App or Browser Version: RocketChat Desktop app 4.1.1
- Operating System: macOS 15.1.1 Sequoia
Server Setup Information:
- Version of Rocket.Chat Server: 6.11 (reported by https://chat.example.com/api/info )
- License Type: Community
- Number of Users: ca 20
- Deployment Method: docker
- Operating System: ?
- Number of Running Instances: ?
- DB Replicaset Oplog: ?
- NodeJS Version: ?
- MongoDB Version: ?
Please follow the bug reporting guides.
You need to test this on the latest code - 7.1.x or open.rocket.chat
Thanks.
Using the app.
In channel.
Overview screen.
Needs testing with desktop & push notifications.
I assume your screenshot originates from the newest 7.1.x and you thereby confirm the bug, right?
I assume your screenshot originates from the newest 7.1.x and you thereby confirm the bug, right?
You know what they say about assume?
That as on open.rocket.chat which is always latest develop code.
HOWEVER.
The URL is fine in the channel - no corruption. Both on Mobile and Browser.
The URL is corrupted in the Channel overview screen as above on Mobile.
I have not yet tested how it looks in a push notification - I presume you are talking about the pop up notification from the app or browser rather than an email or mobile notification?
I have asked the team to look.
Team is checking into it
@reetp My screenshots depict the push notifications of the standalone (Electron based) Desktop apps running on macOS and Windows respectively (as stated in my environment info block).
@casalsgh Thanks for looking into it.
@reetp
Please don't '@' people. I don't work here and have more than enough notifications already.
Thanks.
That false "over eager" Emoji identifier text replacement in the push notification preview also happens with inline-code and code-blocks. Screenshot:
Yes, I just confirmed it by checking on latest code.
The same behaviour with user's Custom status - attached the ss
Expected behaviour :
Emoji Unicode symbol should appear only if user chooses to select
Actual :
Even if user do not choose, emoji appears