-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add an option to require a click to insert emoji from the picker #6150
Comments
This is, frankly, the last UI annoyance I have with Riot. Otherwise, I am extremely happy with it as a client. It adds this trash onto my messages sometimes, and I tend to use a lot of emoticons which exacerbates the problem. |
fb messenger requires an overt click; slack has the same behaviour as Riot does today. This is tough, because it's hard to strike a balance between customisable behaviour and too many checkboxes in the settings panel. That said, we currently expose such fine-grained configuration features as choose-your-own-autocomplete-delay, so having the ability to choose whether autocomplete picking is triggered by mouseover or mouse click certainly is in line with that, philosophically. Perhaps the answer is to add (yet) another customisable option for this, and then when we come to rework the settings UI make sure that composer settings are somehow sensibly and clearly grouped. |
tbh, I'd prefer the default to be requiring a click/tab/positive action as mentioned in the OP. I'm also often bitten by the mouse problem (granted, this might be a result of Riot not having focus on the field all the time, so my mouse is almost always in the area because I'm having to click the composer). |
Isn't this already the default behavior? I can't reproduce your issue in Safari, Firefox, or Chrome on my Mac. For me, Emoji don't get inserted until you tab over to them or click them in Riot 0.16.4 or the current /develop |
This was changed with slate |
Description
In an earlier issue about the emoji picker being over-eager about replacing message content, there was a degree of consensus that acting on mouse-over was intrinsically too aggressive.
However, the ticket was closed after only changing the behavior to require actual mouse movement (as opposed to instantly on the picker opening), rather than after the full change was implemented. This results in subpar UX in various cases, especially when the mouse moves slightly during typing (which happens to me frequently, due to the placement of my touchpad).
Some have expressed a preference for the mouse-over behavior, but could those of us who feel otherwise have an option to disable it?
Steps to reproduce
Instead, I'd expect the user input to be preserved without some form of positive confirmation (click, tab, etc).
The text was updated successfully, but these errors were encountered: