A use case where disabling paste events makes sense:
You want to expose the functionality to make a drastic change on some resource, identified by a string, to the user. Users want this functionality for good reason. It's not reversible, for legal or security reasons. This is a change that could easily destroy the user's company or cost it millions of dollars.
Text specifying what they're doing is insufficient, as users just click through without verifying. Even a checkbox does nothing to make them pay attention. Even an input where they specify what resource they're performing this action on isn't enough, as two users have reported that they just copied and pasted the id of the resource instead of typing it in.
Sometimes you want to break the consistent interface. I don't think "verify that you typed in the password you wanted to for some shitty small company's website" rises to that level, but there are legitimate reasons to drastically increase the cognitive load involved in simple actions by breaking the uniform interface.
If you need to do something like this, do it separately from the actual input. For example, something like "type in the name of the account you're trying to delete".
An example of what GP is talking about is Github’s “type the name of the repository to delete it” workflow. Which I appreciate. A typo would just fail to delete, which is the correct response.
The purpose of this input field isn't specifically to make the user type. It's simply to ensure they know the name of the repository they're deleting.
Sure Github could (and do) display the repository name; but users are accustomed to just hitting next without reading written text.
Input boxes (as opposed to buttons) requires user attention because the user has to know what content to place in the input field. Copying and pasting still meets this requirement as the user has to scan for the repository name (i.e. read) then copy and paste that into the field.
> but users are accustomed to just hitting next without reading written text.
This is why you should (almost) always offer undo for any action that would require a confirmation.
A good balance would be Confirmation -> a window of time (5 seconds - 30 days) when undo is possible -> a slightly hidden menu for irreversible confirmation.
You want to expose the functionality to make a drastic change on some resource, identified by a string, to the user. Users want this functionality for good reason. It's not reversible, for legal or security reasons. This is a change that could easily destroy the user's company or cost it millions of dollars.
Text specifying what they're doing is insufficient, as users just click through without verifying. Even a checkbox does nothing to make them pay attention. Even an input where they specify what resource they're performing this action on isn't enough, as two users have reported that they just copied and pasted the id of the resource instead of typing it in.
Sometimes you want to break the consistent interface. I don't think "verify that you typed in the password you wanted to for some shitty small company's website" rises to that level, but there are legitimate reasons to drastically increase the cognitive load involved in simple actions by breaking the uniform interface.