Expensify / App

Welcome to New Expensify: a complete re-imagination of financial collaboration, centered around chat. Help us build the next generation of Expensify by sharing feedback and contributing to the code.
https://new.expensify.com
MIT License
3.55k stars 2.89k forks source link

[$500] Document reproducible steps for "Characters missing when typing message in compose box" #34467

Closed mallenexpensify closed 8 months ago

mallenexpensify commented 10 months ago

Coming from here in #expensify-open-source

Occasionally and apparently randomly, when typing in the compose box on NewDot, characters will disappear or be removed.

I've tried to document steps that can be reliably reproduced with no luck. If you're able to, post them and we'll compensate $250.

If needed, comment in here or on the linked Slack thread above.

Upwork Automation - Do Not Edit
  • Upwork Job URL: https://www.upwork.com/jobs/~01cd323eccdbb4d53d
  • Upwork Job ID: 1745951741787557888
  • Last Price Increase: 2024-02-29
Ahmed-Abdella commented 9 months ago

After researching and tests, It seems that this issue is not related to our application. Rather, it seems to be a problem with the MacOS system. I encountered this issue while using Slack, and upon browsing through various Apple discussions, I noticed that many others have faced similar issues.

It is happening regularly while typing fast

Screenshot 2024-02-12 at 4 23 50 AM

Screenshot 2024-02-12 at 4 08 41 AM

Another weird behavior that supports this issue is that I tested typing a letter followed by a space and then another letter, and repeated this process. When I typed slowly, nothing unusual happened. However, when I typed quickly, a random "." was added after some letters. This behavior occurred not only in our application, but also in Github and Slack, and looks like it happens everywhere

Expensify

https://github.com/Expensify/App/assets/77763699/a880f757-5545-48f9-8891-9dafa002e8e6

Github

https://github.com/Expensify/App/assets/77763699/aacdd661-0378-4927-bda5-800c551de456

So, yeah in the end it looks like that the characters missing issue is not related to Expensify, it is about MacOS.

@mallenexpensify @tgolen
You can test this through other applications to confirm this. Also search google for "characters missing on MacOS" or "letters missing on MacOS" and you will find alot of forums and discussions about this behavior, I can provide you some links if you want.

Ahmed-Abdella commented 9 months ago

@jeremy-croff in your state When you click the icon that opens the emoji picker the composer lose focus.

And when you choose the emoji it wil be renderd in the composer. It renders the emoji while the composer is not focused, yeah this actually happens. this behavior is a feature, when you start typing (normal typing, or adding emojis) while the composer is not focused the composer will be focused and the letters added to it.

(Try it by clicking outside the composer and then start typing)

jeremy-croff commented 9 months ago

Only though, related to example above is to do another test and have the console open and see if can sync the time of the bug with something showing in the console. Will try next week.

IF anyone needs access to a high traffic workspace to test, drop your email in here and I'll add ya

Jeremycroff@gmail.com

dragnoir commented 9 months ago

IF anyone needs access to a high traffic workspace to test, drop your email in here and I'll add ya

mosaixel.org@gmail.com

dragnoir commented 9 months ago

steps to reproduce the issue.

1: Open the app with chrome browser where you have devtools installed

2: Disable cache and decrease CPU performance to 6x slowdown

image

3: Start typing on old conversations with lots of chat

If you already tested on this chat, logout and login or clean the local Onyx database. The moment the chat is loaded, there will be an overwelmed tasks on the CPU wish will cause the delay on the input speed

image

tgolen commented 9 months ago

You can test this through other applications to confirm this. Also search google for "characters missing on MacOS" or "letters missing on MacOS" and you will find alot of forums and discussions about this behavior, I can provide you some links if you want.

@Ahmed-Abdella, I both agree and disagree with this. I do agree that I am not convinced it's a problem with our app. But I also do not agree that it is a macOS issue. I do not have the problem in any other application (Slack, GitHub, Notion, Google Docs for example, where I do 99% of my typing).

I do still think that it could be an issue with Grammarly, so I have disabled it for our application and I'm still evaluating to see if it helps the situation.

Ahmed-Abdella commented 9 months ago

@mallenexpensify said that this happened for him most of the time on the Desktop app, I believe that Grammarly can't be added to the Desktop apps(not sure of this), anyway this is happeneing for me without using Grammarly. Also, I found that the same issue happened for many people after searching through apple discussions. @tgolen

jeremy-croff commented 9 months ago

If you slowdown the CPU, you can reproduce the emoji showing and deleting everytime:

https://github.com/Expensify/App/assets/157416545/a61bb08e-c67f-4a12-b356-d8dfb8cd0f87

It's also CPU related not purely focus related, as with less lag in the previous experiment it happened every 2 times

melvin-bot[bot] commented 9 months ago

@mallenexpensify, @getusha Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

mallenexpensify commented 9 months ago

@jeremy-croff , @dragnoir , I've added you to high traffic workspace so you can test there.

On MacOS, I also don't experience the issue in/with other applications. I've noticed it 100+ times in the Desktop app and I would have noticed in Slack, gmail and other spots if it happened frequently.

Thanks everyone for chiming in here, let's keep this discussion going til we are able to definitely reproduce.

mallenexpensify commented 9 months ago

Here's a weird twist... I was editing a block of text, midway through, the cursor went back one space then relocated to the end of the text block. So.. maybe we most-often see the bug as just affecting the last character or two but it really affects one character then the cursor refocuses to the end.

melvin-bot[bot] commented 9 months ago

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

tgolen commented 9 months ago

I have witnessed that as well, Matt. It seems to happen less frequently, but I feel it's related.

Also, to report back about Grammarly, disabling it hasn't stopped this from occurring.

On Thu, Feb 15, 2024 at 9:00 AM melvin-bot[bot] @.***> wrote:

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

— Reply to this email directly, view it on GitHub https://github.com/Expensify/App/issues/34467#issuecomment-1946399813, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJMAB57IKN73B4Z6TTELALYTYWLDAVCNFSM6AAAAABBY25OUGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNBWGM4TSOBRGM . You are receiving this because you were mentioned.Message ID: @.***>

wildan-m commented 9 months ago

Hi, I have identified the bug.

The bug can be triggered by pressing a keyboard character every second.

Ideally, the interval should be around 1 second (debouncedSaveReportComment interval) to consistently reproduce it.

While it is possible to do it manually, it can be cumbersome as hitting the keyboard at exact intervals is challenging.

It is more efficient to automate this process using a macro application, such as AppleScript in my case.

on run
    repeat
        tell application "System Events"
            keystroke "W"
            delay 1
        end tell
    end repeat
end run

Here is some information about the issue:

Here is the video to replicate it (Left: Script, Middle: Chrome Browser, Right: Desktop App)

https://github.com/Expensify/App/assets/11847279/c5a0a9fb-0713-48bc-ae28-1637e35f9a8f

To replicate @mallenexpensify's bug we can modify the test code to type 'blurps ' and it shows so many stripped characters

on run
    set textToType to "blurps "

    repeat
        emulateTyping(textToType)
        delay 1
    end repeat
end run

on emulateTyping(textToType)
    tell application "System Events"
        repeat with i from 1 to count of characters of textToType
            set currentChar to character i of textToType
            keystroke currentChar
            delay 1
        end repeat
    end tell
end emulateTyping

Result (using non-high-traffic account, 1:1 chat, latest staging):

https://github.com/Expensify/App/assets/11847279/bbd4a6dd-7991-4f06-a83d-d52c6a58e4a7

Victor-Nyagudi commented 9 months ago

Version Number: Latest (going off of @mallenexpensify being able to reproduce the bug recently) Reproducible in staging?: y (based on Matt reproducing it) Reproducible in production?: y (I'm assuming Matt uses the production desktop app) If this was caught during regression testing, add the test name, ID and link from TestRail: Email or phone of affected tester (no customers): Logs: Expensify/Expensify Issue URL: Issue reported by: @Victor-Nyagudi Slack conversation: https://expensify.slack.com/archives/C01GTK53T8Q/p1704311664219129

Action Performed:

Pre-condition: You'll need to be able to see the Onyx merge calls, so have the console open.

  1. Open a chat with very many messages/long chat history.
  2. Type a few letters in the composer so that the most recent Onyx call is a merge(). You should see a message like this:
[info] [Onyx] merge() called for key: reportDraftComment_31984933430 (this is a random number I just came up with) 
  1. This is the difficult part. As you type a word, try and match your keystrokes such that you synchronize the character you type with the next merge call log on the console.

In other words, type a couple of letters just as the number to the left of the merge call increases. You'll need to try this multiple times, but if you do it just right, some letters will be deleted and maybe retyped.

I've had some slightly better luck when trying to reproduce this offline.

Additionally, I was able to reproduce this by after clicking on the composer, moving the cursor away from it and then trying to synchronize keystrokes with the Onyx merge calls.

Expected Result:

The user is able to type characters and words as usual without any problems.

Actual Result:

Some characters are randomly deleted.

Workaround:

It's rare for a user to time their keystroke perfectly with the Onyx merge call, so even though it happens, it does so rarely, and a user can proceed as usual.

Plarforms:

Which of our officially supported platforms is this issue occurring on?

Screenshots/Videos

Add any screenshot/video evidence

Mac Desktop https://github.com/Expensify/App/assets/79470910/ae1fb3cf-5655-4dc2-a6dd-b1e7e7ca7426 Above, I wanted to write "just as I'm typing" but the "I" in "I'm" got deleted. https://github.com/Expensify/App/assets/79470910/7cb23f1a-c370-4d4d-bef1-0fb5fe64ab62 I wanted to type "maybe another" but the "a" got deleted there at the end. https://github.com/Expensify/App/assets/79470910/27902c9c-19be-4620-b57d-17ec8774ea13 The "t" in "to" got deleted. Did this one while offline.
Mac Chrome https://github.com/Expensify/App/assets/79470910/d3d2bd23-41ac-494b-b6a7-70477873fa95 The "w" in "with" got deleted here.
Mac Safari https://github.com/Expensify/App/assets/79470910/f31711d0-484c-4da4-b30a-13f88515323c I wanted to type "maybe I'm" but the "I" and "m" got deleted.

If you keep your eye on the number beside the most recent Onyx merge call in the console in all the videos the moment the character is erroneously deleted, you'll notice that two calls happen in rapid succession.

jeremy-croff commented 9 months ago

Hi, I have identified the bug.

The bug can be triggered by pressing a keyboard character every second.

Ideally, the interval should be around 1 second to consistently reproduce it.

While it is possible to do it manually, it can be cumbersome as hitting the keyboard at exact intervals is challenging.

It is more efficient to automate this process using a macro application, such as AppleScript in my case.

on run
  repeat
      tell application "System Events"
          keystroke "W"
          delay 1
      end tell
  end repeat
end run

Here is some information about the issue:

  • I encounter it more frequently with wider text characters, in my test 'W' letter triggers more bugs than 'c'
  • The issue can be replicated in any chat type: Workspace / 1:1 / Room
  • When using the above script, if it occurs less frequently after a long text, double-clicking the text will reset the existing text and it usually happens after around the 6th stroke
  • I encounter it more frequently with the Chrome browser than the desktop app (both of which are actually Chrome)

Here is the video to replicate it (Left: Script, Middle: Chrome Browser, Right: Desktop App)

GMT20240216-101429_Clip_Wildan.M.s.Clip.02_16_2024.mp4

Does this mean OP is a slow typer?

Victor-Nyagudi commented 9 months ago

TLDR of what I suspect is going on:

  1. User tries typing a word e.g. "chocolate".
  2. The keystroke for the "c" at the beginning happens simultaneously with an Onyx merge call. This can happen with any character in the word based on timing.
  3. Composer shows "chocolate" briefly but is re-rendered with what's in Onyx - "hocolate".

Long answer

While doing my investigation, I noticed we're dealing with a valueBeforeCaret variable which is updated when shouldCalculateCaretPosition is true.

https://github.com/Expensify/App/blob/28a1ccc40ad6345338de1951c02146304fb30cd5/src/components/Composer/index.tsx#L126-L131

Since setValueBeforeCaret is fired here, this should trigger a re-render.

However, before the re-render occurs, the value of valueBeforeCaret at this point will be everything you've typed minus the most recent character e.g. "I love chocolat"

I'd like to believe that before this re-render happens, if you time your keystroke perfectly, the letter you just typed (the last "e" at the end of the word "chocolate") shows up just before the composer re-renders.

However, this happens at the same time an Onyx merge is called, thus, for a brief moment, you see the most recent character you typed before the merge completes resulting in what's stored in Onyx ("I love chocolat" - the draft comment) at this point replacing what's currently in the composer ("I love chocolate") as the component re-renders because a setState got called.

~As for the 2 merge calls happening in quick succession, I suspect the first is the initial one that should've happened when you stopped typing briefly, and the second is for when you resumed.~

Just remembered I saw the merge calls only happening after I stopped typing.

jeremy-croff commented 9 months ago

I can confirm reproduction manually, using a metronome (lol). Highly increased occurrences when you sow down CPU speed.

I have stacked all the findings:

  1. Grammarly
  2. Electron
  3. Slow CPU speed
  4. paced typing at 1 char per sec
  5. Console open for info

I added in alternative characters and did it manually to show it can happend to a normal person: I am Typing WUWUWUWU here:

https://drive.google.com/file/d/1xDxS-zwgItYBKB5ytz7W2TShgspB6Ioq/view?usp=drive_link

jeremy-croff commented 9 months ago

It seems in our composer we have debouncedSaveReportComment, at 1000ms. When lowering to 500ms for example, we cannot reproduce the bug with the 1S script. I only seem to be able to reproduce it when I sync the typing speed to the debouncedSaveReportComment setInterval. And increase occurrence with CPU slowdown ( maybe bigger race condition zone )

I also confirmed that my original reproduction steps with the Emoji's, actually no longer occurs when lowering debouncedSaveReportComment to 500ms. These reproductions are all intertwined.

jeremy-croff commented 9 months ago

This code was added 5 months ago and could be the culprit of all this mess

wildan-m commented 9 months ago

@mallenexpensify @getusha @tgolen Can you replicate it following the steps I posted?

Does this mean OP is a slow typer?

@jeremy-croff No, but sometimes we type at a 1-second interval and encounter the bug. I suspect it's due to the 1000ms debouncedSaveReportComment. There could be a race condition causing the bug, but further analysis is needed to assess and determine the optimal solution. Since this post is meant to document the reproducible steps, I think we need to create a new post to discover the optimal solutions.

tgolen commented 9 months ago

Wow, sounds like we are finally on the right track! Keep up the good work!

On Fri, Feb 16, 2024 at 1:10 PM Wildan M @.***> wrote:

@mallenexpensify https://github.com/mallenexpensify @getusha https://github.com/getusha @tgolen https://github.com/tgolen Can you replicate it following the steps I posted https://github.com/Expensify/App/issues/34467#issuecomment-1948125511?

Does this mean OP is a slow typer?

@jeremy-croff https://github.com/jeremy-croff No, but sometimes we type at a 1-second interval and encounter the bug. I suspect it's due to the 1000ms debouncedSaveReportComment. There could be a race condition causing the bug, but further analysis is needed to assess and determine the optimal solution. Since this post is meant to document the reproducible steps, I think we need to create a new post to discover the optimal solutions.

— Reply to this email directly, view it on GitHub https://github.com/Expensify/App/issues/34467#issuecomment-1949260711, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJMAB2OYTNE3DWMIW5XM23YT64K3AVCNFSM6AAAAABBY25OUGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNBZGI3DANZRGE . You are receiving this because you were mentioned.Message ID: @.***>

wildan-m commented 9 months ago

@mallenexpensify @getusha I've updated my submission.

It include @mallenexpensify's case when typing 'blurps'

mallenexpensify commented 8 months ago

Thanks again @wildan-m @Victor-Nyagudi and @jeremy-croff for the continued testing and feedback.
@getusha , 👀 please, as you're the C+. Please review and test the above to see which of the above is the most likely culprit. @jeremy-croff provided a handy list here

Does this mean OP is a slow typer?

I could see it maybe being related to a specific cadence, I feel like it might often happening after I pause for a moment when typing ¯_(ツ)_/¯.

getusha commented 8 months ago

Grammarly

looks like @tgolen was able to repro after disabling it😬

Electron

An electron bug? @jeremy-croff, if yes, i already tried to find if the issue has been logged in their repo.

Slow CPU speed

Just tried this multiple times, no luck.

getusha commented 8 months ago

@mallenexpensify Was able to reproduce this only once using @wildan-m's script. trying it again.

https://github.com/Expensify/App/assets/75031127/db1e5ed9-f0e9-445a-92bc-99b948cb0baf

wildan-m commented 8 months ago

@getusha, please add my second script too. Sometimes it slips our eyes, but incomplete blurps words indicate missed keystrokes. Also, using chrome produces more bugs than the desktop.

jeremy-croff commented 8 months ago

@mallenexpensify Was able to reproduce this only once using @wildan-m's script. trying it again.

https://github.com/Expensify/App/assets/75031127/db1e5ed9-f0e9-445a-92bc-99b948cb0baf

Did you try the metronome and slowed CPU speed? This is the only way to reproduce it manually. Maybe I should've been clearer. The script reproduces it, and I performed this manually to isolate the bug further to confirm the script works to reproduce it based on interval. However, it requires a lot of focus manually to do it manually, but the video shows you it's how it's reproduced.

I also believe I proved that it's related to the code I referenced because after editing those values, even the script cannot reproduce it anymore.

getusha commented 8 months ago

@jeremy-croff was able to reproduce it using metronome without slowing down the cpu

https://github.com/Expensify/App/assets/75031127/d3072cf8-b523-4d95-b23a-19cc3b8d2cac

the question is how reliable is this? for example, the script worked once then i am not able to repro again. if i can reproduce this at least 6 times out of 10. we can proceed with it.

jeremy-croff commented 8 months ago

@jeremy-croff was able to reproduce it using metronome without slowing down the cpu

https://github.com/Expensify/App/assets/75031127/d3072cf8-b523-4d95-b23a-19cc3b8d2cac

the question is how reliable is this? for example, the script worked once then i am not able to repro again. if i can reproduce this at least 6 times out of 10. we can proceed with it.

I seem to be able to reproduce it also without slowing down CPU, just much harder.

And I can consistently reproduce it with the script by sending the message after it occurs once, as it seemed less likely to happend twice in the same message

mallenexpensify commented 8 months ago

It's particularly bad for me right now in chat with Chronos for drafting my 10am. Had, at least, 3 instances where characters were missed.

@getusha (and others, if you want) can you review the vid below to see what shows in the console when the l is removed at the end of the test? I'm wondering if that has anything to do with the bug.

https://github.com/Expensify/App/assets/22508304/6131744a-532a-4b6a-8188-249789ff51a2

mallenexpensify commented 8 months ago

Just happened again in a different chat and it looks to be the same in the console at that time!

image
getusha commented 8 months ago

Interesting, was able to track that log to this line, https://github.com/getusha/App/commit/98bb17747372770ac08fe6847fcee0ac826383b5#diff-3eab019f4e3637c02ef9e920269b24b28d08b76356021c19c4d117ef63c54277R191-R193 as @jeremy-croff mentioned. i think yes it is related to that, removing the 1s debounce seem to fix the issue, will ask the author the purpose of that function.

jeremy-croff commented 8 months ago

Yeah, I thought posting manual reproduction steps, as well as a single line of code you can change to mitigate the bug was a slam dunk for an RCA :P

wildan-m commented 8 months ago

@getusha, in my opinion, identifying the root cause and finding the optimal solution is the next step, which does not align with the title of this post. Debouncing a function helps in reducing the number of calls to a function, particularly when it involves quick triggers such as typing. I don't think debouncing is the main problem here; it's pretty common. The problem might actually be in the saveReportComment function, but more investigation is required.

wildan-m commented 8 months ago

@getusha (and others, if you want) can you review the vid below to see what shows in the console when the l is removed at the end of the test? I'm wondering if that has anything to do with the bug.

@mallenexpensify Yes, the onyx save trigger happens when we call saveReportComment, and it will happen more frequently when we type at a one-second interval (our current debounce interval).

wildan-m commented 8 months ago

the question is how reliable is this? for example, the script worked once then i am not able to repro again. if i can reproduce this at least 6 times out of 10. we can proceed with it.

@getusha Utilize the script to select words that have minimal intersections and a broader range of characters.

WA -> It has intersection Hello -> contain double "l" that have less character width

I can produce more frequently using the words "blurps" and "JUMP" 5 out of 16 image

https://github.com/Expensify/App/assets/11847279/573d140b-b376-491d-8550-007b606f5a88

image
wildan-m commented 8 months ago

@getusha @mallenexpensify To increase error occurrences, we can reduce the debounce interval to 100 ms.

Change the code to:

    const debouncedSaveReportComment = useMemo(
        () =>
            _.debounce((selectedReportID, newComment) => {
                Report.saveReportComment(selectedReportID, newComment || '');
            }, 100),
        [],
    );

And change test script to:

on run
    set textToType to "hello "
    repeat
        emulateTyping(textToType)
        delay 1
    end repeat
end run

on emulateTyping(textToType)
    tell application "System Events"
        repeat with i from 1 to count of characters of textToType
            set currentChar to character i of textToType
            keystroke currentChar
            delay 0.1
        end repeat
    end tell
end emulateTyping

It's important to keep a 1-second delay between each word loop; otherwise, we won't be able to manually escape the script loop and will need to force restart macOS.

https://github.com/Expensify/App/assets/11847279/ec8aca98-9e7c-4384-b95a-fbc4f1bffd71

image
AndrewGable commented 8 months ago

I have had this happen to me when I am typing really fast

wildan-m commented 8 months ago

I have had this happen to me when I am typing really fast

@AndrewGable, troubleshooting is challenging without recording it. My assumption is that you take breaks while typing, triggering the debounce interval. I suspect a potential race condition between the debounce interval and our custom typing handle, causing it to not consistently occur.

mallenexpensify commented 8 months ago

My assumption is that you take breaks while typing, triggering the debounce interval. I suspect a potential race condition between the debounce interval and our custom typing handle, causing it to not consistently occur.

This makes sense for my use cases. The bug seems to happen semi-frequently but more frequently when I'm not typing at a consistent speed or if I pause, backspace/delete or slow/fasten my pace of typing.

mallenexpensify commented 8 months ago

The bug is much, much worse for me the past two days, anyone else? I'm on Version 1.4.43-7, desktop. @getusha do we have reliable reproducible steps so that we can create an issue for the job? If so, can you document them.

If/when we create a job, y'all on here will have dibs for submitting proposals before it gets open to external contributors. (we'll also discuss potential compensation for this issue once the job is created).

getusha commented 8 months ago
  1. Open Script Editor (Mac)
  2. New Document > Paste the following script
    
    on run
    set textToType to "JUMP "
    repeat
        emulateTyping(textToType)
        delay 1
    end repeat
    end run

on emulateTyping(textToType) tell application "System Events" repeat with i from 1 to count of characters of textToType set currentChar to character i of textToType keystroke currentChar delay 1 end repeat end tell end emulateTyping


3. Press the play button (run the script)
4. Focus the desktop newDot app composer
5. Wait until you observe that a letter from the word 'JUMP' is being omitted after being typed.

**Expected result:**
The word 'JUMP' needs to be typed with consistency in the composer. **ignore the first word it is because we had a delay when focusing the input.**

**Actual result:**
After a few tries character gets omitted and the word becomes inconsistent. i.e. `JUMP JUMP JMP`

https://github.com/Expensify/App/assets/75031127/65090f16-9610-456c-8490-201064151216
getusha commented 8 months ago

@mallenexpensify i was able to reproduce this 5/5 times running the script, try ^ and let me know.

wildan-m commented 8 months ago

@getusha from the video seems you mean delay 1 instead of delay 0.1

getusha commented 8 months ago

@wildan-m it is delay 1 works well i don't see the need to modify the code to reproduce.

wildan-m commented 8 months ago

@getusha I mean this part

Screenshot 2024-02-22 at 16 03 46
getusha commented 8 months ago

oh thanks, i didn't notice that.

melvin-bot[bot] commented 8 months ago

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

mallenexpensify commented 8 months ago

Me again!! Desktop is the worst it's ever been so I closed it and was testing on Web/Chrome. I was unable to reproduce on web, which makes me wonder if part of the issue is related to cache/cookies/storage or similar (not an engineer!).

Based on the above, I sent into our new Troubleshooting feature, I cleared cache and restarted and it's much better. I wasn't able to reproduce the missing characters... yet. Will report back if/when I'm able to.

image