Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Replay] Keyboard input should count as user-activity and extend the life of a session #6532

Closed
ryan953 opened this issue Nov 21, 2022 · 4 comments · Fixed by #8051
Closed

Comments

@ryan953
Copy link
Member

ryan953 commented Nov 21, 2022

If we don't count keyboard events, then a18n use cases, or power-users that use the keyboard a lot could be completely ignored in some apps.

@mydea mydea transferred this issue from getsentry/sentry-replay Dec 14, 2022
@mydea mydea changed the title Keyboard input should count as user-activity and extend the life of a session [Replay] Keyboard input should count as user-activity and extend the life of a session Dec 14, 2022
@github-actions
Copy link
Contributor

github-actions bot commented Jan 5, 2023

This issue has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you label it Status: Backlog or Status: In Progress, I will leave it alone ... forever!


"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Jan 12, 2023
@p-himik
Copy link

p-himik commented May 3, 2023

Just noticed this as well - saw some really strange behavior on a replay and couldn't grasp what was going on initially. Turned out, a user was hitting a key combination that the app handles but Sentry wasn't showing that.

@mydea mydea reopened this May 4, 2023
@mydea
Copy link
Member

mydea commented May 4, 2023

Hi @p-himik ,

thanks for writing in.
I fear collecting which keys are pressed is not really feasible, from a PII perspective - we can't easily determine why a key is pressed, and we would def. not want to capture e.g. what a user types into a field (imagine us capturing a breadcrumb for each key pressed while a user types into a password field... 😓 ). I think the use case of capturing keyboard shortcuts is valid, though. I wonder how we could identify this... maybe only capture the keys pressed when no input is focused? I guess this may be safe to do... WDYT @ryan953 / @billyvg / @bruno-garcia

@p-himik
Copy link

p-himik commented May 4, 2023

Things that are useful in my own projects:

  • Capturing some particular or all keys when no input is focused (still problematic because a user might start typing some PII while thinking that the right input is focused, without looking at the screen)
  • Capturing key combinations with modifiers regardless of what is focused (Ctrl+z being the most salient one, probably)
  • Knowing that a regular character key has been entered into an input field (this is probably already handled, don't recall)

Personally, I would be quite happy if there were these things implemented:

  • If a key is pressed with Ctrl/Alt/Command/Option, log it
  • If a key is not a character, log it (Home, End, arrow keys, etc.)
  • If a key is pressed without a modifier or with Shift, log only the fact that something has been pressed, without writing the key itself
  • Have an ability to override the above for particular keys, maybe in particular contexts (e.g. suppose I'm emulating Vim on my page - I would like to log all navigation but avoid logging in the Insert mode)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants