Clipboard input in many devices is not detected as paste

[Aaryan-Dadu]

Did you clear cache before opening an issue?

• I have cleared my cache

Is there an existing issue for this?

• I have searched the existing open and closed issues

Does the issue happen when logged in?

Yes

Does the issue happen when logged out?

Yes

Does the issue happen in incognito mode when logged in?

Yes

Does the issue happen in incognito mode when logged out?

Yes

Account name

aaryandadu

Account config

No response

Current Behavior

when using monkeytype on many devices text inserted via the clipboard is not detected as a paste action thus leading to absurd results. This most probably caused because clipboard based input method does not trigger OS level paste event that the event listeners listens for.

Monkeytype.mp4

Expected Behavior

This type of paste by the clipboard should be disabled. I looked into the possible solutions we can move towards but I think that the better approach would be to detect max 1 character per keystroke, multiple characters in one key stroke could be blocked.

Steps To Reproduce

1. Use Gboard in any device or built-in clipboard by One UI.
2. Copy the text from the preview in monkeytype in any mode
3. Paste the copied text using the clipboard

Monkeytype-2.mp4

Environment

• OS:
• Browser:
• Browser Version:

Anything else?

No response

[Arjav1512]

I can reproduce this on mobile (Gboard / One UI). It looks like clipboard insertion often doesn’t trigger a native paste event, so Monkeytype treats it like normal typing.

Before opening a PR, my plan is to block any “bulk insert” at the input layer: listen to beforeinput and prevent events like insertFromPaste and any insertText where e.data.length > 1. As a fallback for devices that bypass beforeinput, we can detect sudden value jumps in input and revert. This should reliably disable clipboard pastes across mobile keyboards without relying on OS paste events.

[Aaryan-Dadu]

I can reproduce this on mobile (Gboard / One UI). It looks like clipboard insertion often doesn’t trigger a native paste event, so Monkeytype treats it like normal typing.

Before opening a PR, my plan is to block any “bulk insert” at the input layer: listen to beforeinput and prevent events like insertFromPaste and any insertText where e.data.length > 1. As a fallback for devices that bypass beforeinput, we can detect sudden value jumps in input and revert. This should reliably disable clipboard pastes across mobile keyboards without relying on OS paste events.

I don't know why the monkeytype has been designed in such a way to accept burst insert as input so will have to look and discuss about it, so its better not to jump to PR right now

[Arjav1512]

I can reproduce this on mobile (Gboard / One UI). It looks like clipboard insertion often doesn’t trigger a native paste event, so Monkeytype treats it like normal typing.
Before opening a PR, my plan is to block any “bulk insert” at the input layer: listen to beforeinput and prevent events like insertFromPaste and any insertText where e.data.length > 1. As a fallback for devices that bypass beforeinput, we can detect sudden value jumps in input and revert. This should reliably disable clipboard pastes across mobile keyboards without relying on OS paste events.

I don't know why the monkeytype has been designed in such a way to accept burst insert as input so will have to look and discuss about it, so its better not to jump to PR right now

Makes sense. I won’t jump into a PR yet.
If you decide burst inserts should not count as normal input, I am happy to help with an approach that blocks beforeinput paste-type inserts and adds a small fallback for mobile keyboards that bypass native paste events. Just let me know what direction you want to take and I can adjust accordingly.