AllBugsFeaturesChangelogBountiesSearchNew post
Sign in with Fluxer
Bugs

[UPDATED] Caret disappears on Home/End toward a custom emoji, and Left arrow from after a line-start emoji jumps the caret to the line above

(#4290) Bug Open: Needs triage desktop emoji messaging ui
by mangafan edited

Reproduction steps

Edit: See comment below with the zip for conclusive research on the bugs

Reproduction steps A. Home / End
  1. Click the message field.
  2. Insert a custom emoji from the emoji picker as the first thing on the line.
  3. Type "hello" after it. The caret is now at the end of the line.
  4. Press Home.
  5. Type a letter.
  6. Clear the field. Type "hello", then insert a custom emoji at the end of the line.
  7. Click between "he" and "llo", press End, then type a letter.
B. Left arrow beside an emoji at the start of a line
  1. Click the message field and type "hello".
  2. Press Shift+Enter to start a second line.
  3. Insert a custom emoji. It is now the first thing on line 2, with the caret right after it.
  4. Press Left once.

Expected behaviour

A. Home puts the caret before the emoji at the start of the line. End puts it after the emoji at the end of the line. Typing works in both cases. B. Left moves the caret from just after the emoji to just before it, on line 2: hello E| -> |E

Actual behaviour

A. After Home (step 4) or End (step 7), the caret disappears and typing does nothing. B. The caret jumps to line 1 instead of stopping before the emoji on line 2: hello hello| E| -> E [Add: after pressing Left, does a typed letter go on line 1 or before the emoji? Does Right arrow do the same thing the other way?]

Build information

Stable Desktop 2026.1018.223338, Web 2026.1018.223338, Electron 44.4.1, Chrome 152.0.7977.78, Node 24.21.0, Locale en-US As for the Platform I only tested on Windows, Desktop app, perhaps it applies to other OS's too though.

Platform

Windows

Evidence

Reproduced with custom emoji. Tested with a standard Unicode emoji too: not reproduced Possibly related: the composer may give the caret two positions at the emoji's edge (end of the previous line vs. start of the emoji's line), and the browser draws it in the wrong one or in no visible spot.

5 comments

Sign in with Fluxer to comment and vote.
Comment by Fullest
FullestReviewer 1 vote 3 replies
Hi, so I can reproduce part of bug A but none of bug B on Canary Desktop 2026.1018.223341, Web 2026.1018.223341, Linux 7.2.11-200.fc44.x86_64 (x64), Electron 44.4.1, Chrome 152.0.7977.78, Node 24.21.0, Locale en-US I'm hesitant to change the status on this report however, because there are multiple things here and I can't reproduce all parts of this. I think it would do well for everyone's sanity if you split this up into two or three reports. One for each bug you are pointing out. It's more upfront work for you, but it means they can be handled individually. We can also tag posts as related to one another so it's not like some bugs will get missed and only some will get addressed.
Permalink
Comment by mangafan
mangafan OP1 vote 2 replies
okay, i guess i'll close this one and make 2 new bug reports then. give me a bit of time though. and just in case, i updated the desktop client to Stable Desktop 2026.1025.12517 and B was still an issue.
Permalink
Comment by Fullest
FullestReviewer 1 vote 1 reply
Yes, I wasn't trying to imply the bug doesn't exist, but that it might not be universal (specific OS or maybe some specific setting). Thus it would be best to separate these bugs out into their own reports. You can edit this one down instead of closing it btw, but do whatever is easiest for you.
Permalink
Comment by mangafan
mangafan OP1 vote
I've updated this bug with findings on why the bugs exist and also LLM-suggested solutions. I understand that you guys won't review LLM generated code, and I understand why, and I'm not suggesting you do. I'm simply providing all of the information I have in case any of it can be of help. Since the source of the bugs have been identified though, I will not make any new bug reports or edit this one significantly besides adding the zip.
Permalink
Comment by mangafan
mangafan OP1 vote

Update: source of the bugs has been found.

I investigated this further with LLM assistance. I know you guys will not review LLM code, but hopefully the investigation's results themselves will be helpful. The attached ZIP contains a proposed patch (feel free to ignore this), explanations with source files/line numbers, and before/after code snippets. I can reproduce both problems in the desktop client:
  • Home/End near custom emoji: the caret disappears and typing stops. After Home, copying the draft confirms the typed letters aren’t there.
  • Left after a line-start emoji: type hello, Shift+Enter, insert a custom emoji, then press Left and type X. X appears on the previous line instead of before the emoji.
Right arrow works normally in my tests, with or without the trailing space. The proposed patch passes isolated Lexical tests, but hasn’t been tested in a complete Fluxer build. The included HTML is only a browser experiment, not an exact Fluxer reproduction. Could someone review the patch and test it in the full client?
Permalink