CRITICAL: Desktop - Chat Switcher is slow and doesn't recognize keystrokes

kbecciv commented 1 year ago

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

Action Performed:

Type a message in a chat
Type command+k to open chat switcher
Immediately start typing the name of a person you already have chats with

Expected Result:

The characters you type show up in search

Actual Result:

Many characters are missed. ie. I typed lauren quickly and only the n showed.

Workaround:

Unknown

Platforms:

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

[ ] Android / native
[ ] Android / Chrome
[ ] iOS / native
[ ] iOS / Safari
[ ] MacOS / Chrome / Safari
[x] MacOS / Desktop

Version Number: 1.3.73.0 Reproducible in staging?: n/a Reproducible in production?: n/a 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: https://stackoverflow.com/c/expensify/questions/4856 Notes/Photos/Videos: Any additional supporting documentation

n/a

Expensify/Expensify Issue URL: Issue reported by: @mallenexpensify Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1695286362554219

View all open jobs on GitHub

Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~011dba4ca10589e48c
Upwork Job ID: 1707643423922569216
Last Price Increase: 2023-10-17

Issue Owner

Current Issue Owner: @mallenexpensify

cubuspl42 commented 11 months ago

@getusha

IMO reducing the ANIMATED_TRANSITION is definitely a hack

Do you have any arguments for this claim?

I don't have strong feelings about the ANIMATED_TRANSITION constant, but in general, if the transition is long as it is for esthetic reasons, and it actually affects UX of a user who wants to make things done while typing reasonably fast, then it's not impossible that the transition is just too long.

additionally the issue will still be either reproducible even without the setTimeout

I'm not sure if I got this right. Are you saying that reducing ANIMATED_TRANSITION doesn't fix the issue in your case, i.e. you're still reproducing it after reducing ANIMATED_TRANSITION?

or will cause a glitch.

It's possible. What kind of glitches do you have in mind, or is there any specific part of the app that you would test first? Or, alternatively, do you have any past issue in mind that might return after we reduce the mentioned constant?

cubuspl42 commented 11 months ago

We don't have an infinite set of options here, I want to fix this issue, as closing it doesn't feel appropriate; I agree that there is a problem here. I encourage a constructive approach based on evidence or experience. Also, proposals without logical flaws.

cubuspl42 commented 11 months ago

Also, everyone, please note that I suggested an investigation path that nobody picked up, which still might be fruitful.

A link to the original PR introducing/changing the 300 ms constant

Understanding why it was introduced and decided to be 300 ms, not something else

Starting a dialogue with the author/C+ of the original proposal can be considered

Proof of testing the proposed solution in the relevant area, showing that it doesn't add regression to the original problem

cubuspl42 commented 11 months ago

It appears that there is a Slack thread on the internal performance-related channel. We'll have to coordinate efforts!

mallenexpensify commented 11 months ago

@cubuspl42 thanks for the link! Good sleuthing, I hadn't seen.

mallenexpensify commented 11 months ago

I'm bumping this to weekly for now, since there's a discussion going on.

stephanieelliott commented 11 months ago

Coming from this Slack summary it seems like this PR may fix the issue https://github.com/Expensify/App/issues/30261

cubuspl42 commented 11 months ago

I'm not sure why https://github.com/Expensify/App/issues/30261 was created, it sounds like a dupe of this one. I asked a question there

stephanieelliott commented 11 months ago

https://github.com/Expensify/App/issues/30261 still being worked on

cubuspl42 commented 10 months ago

Let's hold on https://github.com/Expensify/App/issues/30261

stephanieelliott commented 10 months ago

Added HOLD status to title, keeping this at Weekly however since it is high priority

cubuspl42 commented 10 months ago

https://github.com/Expensify/App/pull/30263 has been merged; we can put off hold and re-test

stephanieelliott commented 10 months ago

Hey @kbecciv can you retest this one please?

kbecciv commented 10 months ago

@stephanieelliott Checking, will update you shortly!

kbecciv commented 10 months ago

Reproducible with v1.3.96-6. When typing "Dwight" but only "wight" is entered in the search field.

https://github.com/Expensify/App/assets/93399543/7b052c6a-78f2-4ca0-bc72-9d53827085e4

mallenexpensify commented 10 months ago

Still happening for me, but it seems to be better after the below was implemented, just commented there

https://github.com/Expensify/App/issues/30261#issuecomment-1802733010

cubuspl42 commented 10 months ago

Summing up: we know that reducing the ANIMATED_TRANSITION used to help with our bug. After the optimization (https://github.com/Expensify/App/issues/30261), maybe reducing it less will make things right here?

At the same time, I'm aware that even touching ANIMATED_TRANSITION is somewhat risky, as we rely on it in many places. This makes our issue tricky.

mallenexpensify commented 10 months ago

@cubuspl42 do you think this bug is possibly related? ie. that some version of animation is making it take longer to load and recognize keystrokes? https://expensify.slack.com/archives/C049HHMV9SM/p1699896354633069

cubuspl42 commented 10 months ago

@mallenexpensify

In a way, for sure. This issue has two components: the delay introduced by ANIMATED_TRANSITION, and the performance-related delays. The linked case nearly for sure has at least one of these components.

mallenexpensify commented 10 months ago

Thx @cubuspl42 I find it a bit frustrating that we're trading off style and animation over usability. Let's keep the issues separate for now, Im' curious what proposals we might get for the other issue.

cubuspl42 commented 10 months ago

It's not done on purpose, I think.

Nobody said it's unacceptable to lower ANIMATED_TRANSITION, it's just a bit "scary", as it's a global app-wise constant. Something like "move this single thing here and shake the whole app".
We're also dealing with a platform quirk, specifically on the Web; as far as I understand, it's not possible to focus the inputs until the animation is 100.0% complete
We're dealing with animation and performance issues at the same time, it doesn't help

mallenexpensify commented 10 months ago

Thanks @cubuspl42 , I was mostly just whining/griping there for a min. Do you think it's best to put this on hold for now, move to monthly and remove Help Wanted? I'd remove Steph and assign myself. I'm hesitant to just close the issue cuz I'd love to see it fixed at some point, even if it's many months down the road.

cubuspl42 commented 10 months ago

@mallenexpensify

Honestly, I'm not optimistic about this being fixed externally...

From the engineering point of view, the next steps could be:

Investigating how animations and computation performance contribute to the observable issue after https://github.com/Expensify/App/issues/30261#issuecomment-1802733010 was merged
Creating an objective, automated end-to-end performance test that would allow us to measure the impact of potential solutions
Investigating whether the ANIMATED_TRANSITION constant could be lowered, having in mind the app-wise consequences

put this on hold for now,

I'm not sure what we would hold on.

move to monthly and remove Help Wanted?

Then we'd need to assign this to an expert agency or an internal engineer, right?

mountiny commented 10 months ago

@mallenexpensify I think we should close this issue, this is unfortunately basically impossible to fix with the current set up and while its annoying we just need to move on, we are going to update the search soon as part of the ideal-nav so maybe we can make it better there

mallenexpensify commented 10 months ago

I'm going to assign to myself, remove others and make it a monthly. Then, drop into an ideal nav room when the time is right, to insure it's being considered. Thx @mountiny and @cubuspl42

mallenexpensify commented 9 months ago

Checking in Wave 9, that used to be Ideal Nav https://expensify.slack.com/archives/C05NJ4SLBMF/p1703259924998969

mallenexpensify commented 8 months ago

Checking link above to see where this belongs

melvin-bot[bot] commented 8 months ago

Triggered auto assignment to Contributor Plus for review of internal employee PR - @0xmiroslav (Internal)

mallenexpensify commented 8 months ago

Sorry @0xmiroslav , was testing auto-assigner automation

mallenexpensify commented 8 months ago

This appears to have gotten worse. And I fear it's more likely to get worse than better unless we do something about. A minute ago I

Opened chat switcher
Waited 2-3 seconds, knowing it's not recognizing keystrokes
Typed social and then return (pretty quickly)
Chat opened to Shawn somehow

Checking in Wave 9 room https://expensify.slack.com/archives/C05NJ4SLBMF/p1705602710724309

filip-solecki commented 8 months ago

Hi! I am Filip Solecki from Software Mansion - an expert agency and I'd like to work on this issue.

mallenexpensify commented 8 months ago

Thanks @filip-solecki , one other issue that might be related is, it's possible for me to type someone's name and hit enter (quickly), but then the correct chat doesn't open. I can easily reproduce if you want a vid, can also put it on hold and address after the fix for keystrokes not being recognized when first typed.

melvin-bot[bot] commented 8 months ago

Current assignee @mallenexpensify is eligible for the Bug assigner, not assigning anyone new.

melvin-bot[bot] commented 8 months ago

Triggered auto assignment to Contributor Plus for review of internal employee PR - @aimane-chnaif (Internal)

aimane-chnaif commented 8 months ago

Not overdue. Waiting for proposal from @filip-solecki

filip-solecki commented 8 months ago

@mallenexpensify Please upload video mentioned above.

filip-solecki commented 8 months ago

Tbh I think this behavior is more connected to the second issue mentioned here - but can you alse recreate it to let me check this? Unfortunately I cannot recreate this one.

mallenexpensify commented 8 months ago

It always happens for me, just now I was eating a burrito and typed cmd+k then faye only using one hand and fa weren't recognized. Do you have access to a high-traffic account @filip-solecki , if not, can you share a best email address so I can get you added?

mallenexpensify commented 8 months ago

Per discussion here I've put this on hold pending the Fabric update. Updated to weekly and I'll do my best to be patient every... single... time I have to wait a second or two before I start typing after typing cmd+k :)

filip-solecki feek free to post comment/thoughts here, with the understanding this isn't a priority and might, hopefully be fixed with the Fabric update. Also fee free to unassign

filip-solecki commented 8 months ago

I think I requested for high-traffic account but you can check: filip.solecki@swmansion.com.

mallenexpensify commented 8 months ago

I requested to have you added to a high traffic account @filip-solecki

mallenexpensify commented 8 months ago

Here's a 'real world' example of why this is so frustrating. I think it might be getting, or have gotten, worse too. I've had a dozen instances this morn of the bug.

cmd+k
start typing Faye
Assume I'm in my chat with Faye, send three messages to Faye
Notice I'm actually in my chat with Joanie for some reason.

https://github.com/Expensify/App/assets/22508304/5321a35c-8b44-4803-8f05-032e8838cf8e

mallenexpensify commented 7 months ago

Sasha mentions search is snappier here. Has anything been done that'd help explain that? I just did some testing and I agree that it appears to be better, the characters I type don't go missing like they did before.

mallenexpensify commented 7 months ago

Different, but related, bug. Keystrokes are being recognized but, after entering a few characters and clicking enter, the correct chat doesn't load, the old/existing chat persists

https://github.com/Expensify/App/assets/22508304/6b348eda-481a-4fd0-83f5-9999c978e8c7

mallenexpensify commented 7 months ago

Still occasionally run into issues so leaving this open a lil while longer, will add more examples soon.

mallenexpensify commented 7 months ago

For this example, this is my normal typing speed and I can reproduce the bug multiple times.

https://github.com/Expensify/App/assets/22508304/ac78c5e9-c7b5-4deb-b0e4-d61bb84e6722

mallenexpensify commented 6 months ago

Holding on

https://github.com/Expensify/App/issues/8503

mallenexpensify commented 6 months ago

Still waiting on Fabric update which should be soon 🤞 https://github.com/Expensify/App/issues/8503

(posting cuz I just started my day and instantly sent a message to the wrong person cuz of the lag in search)

aimane-chnaif commented 6 months ago

I am going to be OOO soon. I will keep assigned here as held on Fabric update but if this requires C+ attention, please reassign.

mallenexpensify commented 6 months ago

I just noticed that the compose box now seems much laggy than before too. ie. I typed cmd+k, opened chat, started typing Was looking and only okin showed. This has been very noticeable this week. Could this be related or should I post a new bug for it?

Expensify / App