This issue has been around for couple of months, and I can reproduce it here at Meta using an Android/Chrome device (both latest) – actually this has been happening for several months, since January or so.
The message editor seems to “crash” every now and then when one chooses a proposed emoji.
Repro steps:
Post a reply to a topic, add some text
Start adding a thumbs up by typing “:+1” and then tap the proposed emoji
What happens:
The editor seems to somehow crash, or is redrawn. Some written text is typically lost.
It is not a 100% repro, but I can easily hit the issue within a minute of fiddling.
But I added quite a few breakpoints and can’t really find “who” is mutating autocompleteOptions and setting it as null.
Having autocompleteOptions be from the scope of the parent closure from two levels up is also quite weird and makes the code a bit hard to follow up/debug.
@ljpp / @falco can you still repro this bug? I’ve tried lots of variations of inserting an emoji and couldn’t repro not even once. If you can still repro, can you share the exact steps please? Thanks!
Just tried and could not easily reproduce this. I am however quite certain that I have seen this over the summer a couple of times, accidentally when typing a real post.
Edit: I’ll ask our community if they could provide more extensive test coverage.
Edit 2: Oh yes, I reproed it myself now. Our community is now testing and looks like there are some more repros by regular users.
Yes it is. Personally I could not reproduce it with 15 minutes of aggressive fiddling, so I asked our community for support. Several users were able to repro and one even proved it with a screenshot. Symptoms are unchanged - once you tap the thumb up -emoji on the selector, the keyboard folds away, and some written content is lost in the editor.
I used to repro this very easily, but now I can’t seem to nail it. So the issue is there, but it is not a 100% repro. We will keep on fiddling and trying to figure out if there is some UI-step that triggers this.
Ok, I’ve looked into this again today and managed to repro after switching the virtual keyboard on my phone to Gboard. Gboard sometimes fires keydown and keyup events twice for a single key press and if that happens for the last key you press before selecting an emoji from autocomplete, you’ll get a crash.
I’m not sure what causes Gboard to fire these events twice, but it seems to depend on what you’ve typed and your Gboard settings.
The double events cause a crash due to the way our autocomplete library is designed. So the library listens to both keydown and keyup events, and on keydown it clears the autocomplete suggestions and on keyup it offers new suggestions based on the new autocomplete term.
However, there is a small guard/optimization to protect the library from doing duplicate work when the term has not changed since the previous suggestions, and this where the issue occurs. The first pair of keydown and keyup events clears the old suggestions and offers new ones as expected, but the second erroneous pair will clear the suggestions again on keydown but won’t offer new ones on keyup because the autocomplete term has not changed.
The only least hacky “fix” that I can think of is removing the guard/optimization so the library always offers new suggestions on keyup, but I’m not sure if this is desired or worth it.
I know that we want to rewrite our autocomplete library at some point (it’s some of the oldest code in the codebase and desperately needs a rewrite), so maybe this bug could wait until we get to the rewrite?
No, the crash is accessing a null variable. When the suggestions are cleared the autocompleteOptions variable is set to null and then when you tap on one of rendered suggestions we expect autocompleteOptions to be an array but it’s null.
This gives me another idea: perhaps we could check if autocompleteOptions is null when a suggestion is selected and if the variable is null then we re-fetch the suggestions for the given term?
Ah, I feel so dumb for not reporting this detail. My previous phone was a clean Android One so it had the Gboard as default, and it has followed me ever since to the next device (Sammy A42 5G). But most Android devices sold today use a 3rd party keyboard app by default