6 ms·

Both of these are stupid but we should blame the OS/browser, there is no reason the site should be able to tell the difference or block pasting in the first pla

Both of these are stupid but we should blame the OS/browser, there is no reason the site should be able to tell the difference or block pasting in the first place.

lxgr 2y ago
Presumably browsers could replace a paste with n “key down” and “key up” events, but I bet that causes other issues elsewhere and doesn’t seem like the right solution. Ultimately, misguided developers or PMs will always find a way to make our lives harder if they set their mind to it; let’s not make it an arms race. That said, for password managers and known-bad sites, your proposal sounds tempting!
- kps 2y ago
  > Presumably browsers could replace a paste with n “key down” and “key up” events Or a single text input event. Key events will get you nowhere in the presence of CJK IMEs, for instance.
  - lxgr 2y ago
    You know that, but do the developers of broken password input fields?
    - kps 2y ago
      The question is whether I know it despite not being a front-end developer, or because of not being a front-end developer. (Around 8–10 years ago I worked on keyboard input for ChromeOS, and way too much of it was trying to emulate 1995 Windows Netscape so that most sites would mostly work.)
- deleted 2y ago
  [deleted]
zamadatix 2y ago
For the vast majority of the time I don't think the site's goal is even to "tell the difference" rather they implemented the form with the wrong event trigger instead of one that makes sense for monitoring inputs. You definitely want these other events in other scenarios so blaming the browser for having them isn't going to help anything.
- pc86 2y ago
  Blocking pasting is intentional 100% of the time.
  - zamadatix 2y ago
    You'd be surprised, even for the paste half of the equation, how many go out of their way to make a completely custom input to do it better™ that fails to support obvious things by happenstance. See the topic's article about looking for number keycodes instead of processing text input as an example.
- OJFord 2y ago
  > they implemented the form with the wrong event trigger Well yeah, but their first mistake was implementing a form text field by listening for event triggers.
kevincox 2y ago
There are actually some good reasons. The default paste action will just paste text or HTML. However most OS clipboards have the ability to paste various types of content. If the clipboard contains a "better" media type it makes sense for the application to handle it and prevent the default action. For example: 1. Pasting an image into a markdown field. A common action is to upload the image and insert the correct markup to embed it. 2. Pasting richer content inside an application. For example when copying a rich widget you may embed a text representation, HTML representation but if the user pastes the widget back into your app it is often best to keep a "native" representation that can be used to faithfully reconstruct the original data.
- macintux 2y ago
  Related, my current rage-inducing gripe is that at $DAYJOB, where I have to use a Windows VDI, pasting text from OneNote into a Jira comment results in a screenshot. I don't know whether OneNote is more to blame (I already hate it because Ctrl-C rarely works to copy) or Jira, or Windows, or who, but it's just maddening. (Clarification: pasting text results in a picture as an attachment. Didn't mean to imply that pasting would actually take a snapshot of the screen.)
  - deely3 2y ago
    Can't test, but what happens if you paste with Shift-Ctrl-V?
    - macintux 2y ago
      Well, of course I now can't reproduce the problem for whatever reason, but I'll keep that trick in my pocket, thanks.
  - mmis1000 2y ago
    fortunately, firefox now has a 'paste as plain text' option. So I can just use it instead.

Both of these are stupid but we should blame the OS/browser, there is no reason the site should be able to tell the difference or block pasting in the first place.

lxgr 2y ago

Presumably browsers could replace a paste with n “key down” and “key up” events, but I bet that causes other issues elsewhere and doesn’t seem like the right solution. Ultimately, misguided developers or PMs will always find a way to make our lives harder if they set their mind to it; let’s not make it an arms race. That said, for password managers and known-bad sites, your proposal sounds tempting!

kps 2y ago
> Presumably browsers could replace a paste with n “key down” and “key up” events Or a single text input event. Key events will get you nowhere in the presence of CJK IMEs, for instance.
- lxgr 2y ago
  You know that, but do the developers of broken password input fields?
  - kps 2y ago
    The question is whether I know it despite not being a front-end developer, or because of not being a front-end developer. (Around 8–10 years ago I worked on keyboard input for ChromeOS, and way too much of it was trying to emulate 1995 Windows Netscape so that most sites would mostly work.)
deleted 2y ago
[deleted]

zamadatix 2y ago

For the vast majority of the time I don't think the site's goal is even to "tell the difference" rather they implemented the form with the wrong event trigger instead of one that makes sense for monitoring inputs. You definitely want these other events in other scenarios so blaming the browser for having them isn't going to help anything.

pc86 2y ago
Blocking pasting is intentional 100% of the time.
- zamadatix 2y ago
  You'd be surprised, even for the paste half of the equation, how many go out of their way to make a completely custom input to do it better™ that fails to support obvious things by happenstance. See the topic's article about looking for number keycodes instead of processing text input as an example.
OJFord 2y ago
> they implemented the form with the wrong event trigger Well yeah, but their first mistake was implementing a form text field by listening for event triggers.

kevincox 2y ago

There are actually some good reasons. The default paste action will just paste text or HTML. However most OS clipboards have the ability to paste various types of content. If the clipboard contains a "better" media type it makes sense for the application to handle it and prevent the default action. For example: 1. Pasting an image into a markdown field. A common action is to upload the image and insert the correct markup to embed it. 2. Pasting richer content inside an application. For example when copying a rich widget you may embed a text representation, HTML representation but if the user pastes the widget back into your app it is often best to keep a "native" representation that can be used to faithfully reconstruct the original data.

macintux 2y ago
Related, my current rage-inducing gripe is that at $DAYJOB, where I have to use a Windows VDI, pasting text from OneNote into a Jira comment results in a screenshot. I don't know whether OneNote is more to blame (I already hate it because Ctrl-C rarely works to copy) or Jira, or Windows, or who, but it's just maddening. (Clarification: pasting text results in a picture as an attachment. Didn't mean to imply that pasting would actually take a snapshot of the screen.)
- deely3 2y ago
  Can't test, but what happens if you paste with Shift-Ctrl-V?
  - macintux 2y ago
    Well, of course I now can't reproduce the problem for whatever reason, but I'll keep that trick in my pocket, thanks.
- mmis1000 2y ago
  fortunately, firefox now has a 'paste as plain text' option. So I can just use it instead.