Closed mallenexpensify closed 8 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
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.
@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)
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
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
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
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.
@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
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
@mallenexpensify, @getusha Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!
@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.
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.
📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸
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: @.***>
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
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
Pre-condition: You'll need to be able to see the Onyx merge calls, so have the console open.
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)
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.
The user is able to type characters and words as usual without any problems.
Some characters are randomly deleted.
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.
Which of our officially supported platforms is this issue occurring on?
Add any screenshot/video evidence
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.
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?
TLDR of what I suspect is going on:
Long answer
While doing my investigation, I noticed we're dealing with a valueBeforeCaret
variable which is updated when shouldCalculateCaretPosition
is true
.
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.
I can confirm reproduction manually, using a metronome (lol). Highly increased occurrences when you sow down CPU speed.
I have stacked all the findings:
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
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.
This code was added 5 months ago and could be the culprit of all this mess
@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.
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: @.***>
@mallenexpensify @getusha I've updated my submission.
It include @mallenexpensify's case when typing 'blurps'
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 ¯_(ツ)_/¯.
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.
@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
@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.
@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.
@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 was able to reproduce it using
metronome
without slowing down the cpuhttps://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
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
Just happened again in a different chat and it looks to be the same in the console at that time!
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.
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
@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.
@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).
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
https://github.com/Expensify/App/assets/11847279/573d140b-b376-491d-8550-007b606f5a88
@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
I have had this happen to me when I am typing really fast
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.
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.
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).
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
@mallenexpensify i was able to reproduce this 5/5 times running the script, try ^ and let me know.
@getusha from the video seems you mean delay 1
instead of delay 0.1
@wildan-m it is delay 1
works well i don't see the need to modify the code to reproduce.
@getusha I mean this part
oh thanks, i didn't notice that.
📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸
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.
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