Hacker News Reader

Comment by progbits | Hacker News Reader

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.

View on HN

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.

Blocking pasting is intentional 100% of the time.

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.

> 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.

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.

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.)

Can't test, but what happens if you paste with Shift-Ctrl-V?

Well, of course I now can't reproduce the problem for whatever reason, but I'll keep that trick in my pocket, thanks.

fortunately, firefox now has a 'paste as plain text' option. So I can just use it instead.

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!

> 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.

You know that, but do the developers of broken password input fields?

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.)

Reply on news.ycombinator.com