Live data from Hacker News

Don't touch my clipboard

alexanderell.is

261–270 of 322 posts

Re: Don't touch my clipboard

#261

Earlier quoted context omitted.

Not sure I follow, how should the argument display the rich text (markup/formatting instructions) before the selection? The displayed/selected content might be Foo Bar but the content I want on the clipboard could be Foo Bar but I never want to see the markup, only the formatted text. I don’t want to make a two step function where I need to reveal a textual description of the content and select that. The markup might…

That would be unsupported functionality. You cannot both have transparent copy capability and copy hidden content without revealing it. Copying visual content would be subject to different requirements and limitations. But for text: what you see is what you get. If you're copying glyphs alone, those are what are copied. If you want formatting, you'll need to have the source application reveal that.

It could be an option that is revealed after a warning. "This page wants to use the javascript 'copy' event to place transformed data on the clipboard. If you accept it would place [data shown] on the clipboard, otherwise it would place [raw text] on the clipboard". What do you want to do? copy text? copy data? [ ]remember my choice for this site.

Here, data shown would probably be some info about the data rather than the data itself. It could be a 2mb base64 bitmap...

However, perhaps a better alternative would be to offer both "copy text" and "copy" where the former just copies selected glyphs as plaintext while copy fires the js event allowing the transform.

The important thing to remember is that webpages in 2020 must work like users expect desktop applications to work, and interact with desktop applications (e.g. copy rich content from webpage to desktop must be a default enabled feature or the user will consider the browser broken). For this reason, I don't think it's a viable solution to disable the js event by default (i.e. to hook Ctrl+C to the "copy text" function).

Re: Don't touch my clipboard

#262
I used to work for a big ad-tech company(the company is sold and closed now). I was a guy who developed a tool with this functionality. As a publisher, you can add a text with a link(plus tracking code) to every copied peace of text from your webpage. Something like: "Read more at: "" rel="nofollow">https://example.com/my-article/#"

It's not about copyright. As a website owner, you can disable this behavior, but by default, it was enabled. The main purpose of this functionality was to track shares(for example if you copy text and send it to your friend in skype). As i remember it was one of the most popular & important features in the whole toolkit.

In a nutshell, it's about 200 lines of battle-tested javascript-code that worked perfectly fine in almost any browser(dunno about now it was around 3 years ago).

Personally, i hate this behavior.

Re: Don't touch my clipboard

#263
post #99

Earlier quoted context omitted.

Ok but those are standard, valid characters like any others. Why are they ‘horrid’?

Because for some reason terminals are stuck in the 70ies and don't accept those characters as quotes. Anything but ASCII trips them up. Seems such an obvious interface to innovate, but it seems to run into terminal wizards sense of purity.

The idea that "terminal wizards" reject this is rather undermined by the fact that "terminal wizards" made open and close double quotation marks accessible as simply [Group2]+[B04] and [Group2]+[B05] on an ISO 9995-3 conformant keyboard.

Or [Shift]+[Option] [B04] and [Shift]+[Option] [B05] if there's no explicit [Group2] shift.

Open and close single quotation marks use the same keys.

"terminal wizards" have done quite the opposite of rejecting this.

Re: Don't touch my clipboard

#264

On a related note, I find it interesting how modern US-ANSI layout keyboards (even the International version [1]) still has such a limited set of characters. We have ¼, ½, and ¾, but not en (–) and em (—) dashes; and I get that (') and (") are leftovers from typewriters and ASCII, but wouldn't it be nice to have proper 6-9 (‘…’) and 66-99 (“…”) quotation marks? Then again, you often see Europeans online misusing acut…

See https://news.ycombinator.com/item?id=22357897 .

Re: Don't touch my clipboard

#265
post #68

Earlier quoted context omitted.

MS Word will autocorrect two hyphens into either an en dash or an em dash based on what it believes you were trying to type. So this: "em--dash" becomes this: "em—dash" while this: "en -- dash" becomes this: "en – dash"

On macOS ⌥- = en dash ⇧⌥- = em dash where ⇧ = shift ⌥ = option - = hyphen

Now those are the symbols that I find myself going to a WWW page to copy and paste. Fortunately, it's my WWW page.

* http://jdebp.uk./FGA/iso-9995-7-symbols.html

Re: Don't touch my clipboard

#266
post #88

Earlier quoted context omitted.

I always just type "#" first before pasting... That way it is just a comment I can inspect before running

Here, paste this into your terminal: echo "hello" echo "lol" ; sudo sl -rf / (In case it's not obvious, the # trick will not help you.)

True, the comment trick does not work for multi-line pastes

Re: Don't touch my clipboard

#267

The wrongest thing about this, from my perspective, is that my browser fires off a js 'copy' event when I press control-c. There are times when I've found it helpful that a browser can copy text to my clipboard when I click a button, but I can't think of a single time when I want a site to react to my attempt to copy text off if it. Is there any way to configure my user agent (Firefox) not to do this? A hack is ok.

Under X11, Firefox sets the primary selection correctly and middle-click paste is unaffected. This site also renders fine with JS blocked. That is a useful default to prevent this kind of crap from interfering with you. What is infuriating is CSS that prevents text selection in the first place. That insult to usability should have never been adopted by browsers.

> That insult to usability should have never been adopted by browsers

As a web developer, it's kind of funny seeing people exclaim "this feature should not exist" after seeing a few abuses of it, even though they probably benefit from it every day without realizing it. Overriding copying is needed for wysiwyg editors and selection blocking is needed for many kinds of drag&drop interfaces and also editors.

Instead of complaining that useful features exist because they can be misused, maybe complain about the misuse itself - maybe even to the people actually misusing them. Shoot them an email and they might actually do something about it. Most of these misuses hurt accessibility (screen readers, etc.), so if nothing else, they'll see it as a way to reach more customers.

Re: Don't touch my clipboard

#268

Earlier quoted context omitted.

That would be unsupported functionality. You cannot both have transparent copy capability and copy hidden content without revealing it. Copying visual content would be subject to different requirements and limitations. But for text: what you see is what you get. If you're copying glyphs alone, those are what are copied. If you want formatting, you'll need to have the source application reveal that.

It could be an option that is revealed after a warning. "This page wants to use the javascript 'copy' event to place transformed data on the clipboard. If you accept it would place [data shown] on the clipboard, otherwise it would place [raw text] on the clipboard". What do you want to do? copy text? copy data? [ ]remember my choice for this site. Here, data shown would probably be some info about the data rather tha…

How would you institute that in the clipboard logic and independently of the app?

Because we're no longer operating in a world in which apps or processes are trusted or trustable. Maybe the ones you write, maybe if you're really lucky the ones that come with your fully-vetted Linux distro.

But not npm installs, not proprietary binaries, not website logic, and most especially not the crap that's distributed on mobile app stores.

Your OS, you've got to trust. Which means that the logic's in the clipboard.

And how can the clipboard know that the application is attempting to change contents such that the clipboard won't receive what it is that you see?

That's a key reason I see this as something that 1) has to be in the clipboard logic and 2) has to exclude applications entirely from the copy process. The clipboard should be acting on, say, the graphics render layer directly, outside the application's scope.

Re: Don't touch my clipboard

#269

Earlier quoted context omitted.

Wonder if an author will rename themself sudo rm -rf / with the proper escape codes.

Maybe run `sudo chmod -R 000 /` instead. Can't get charged with destroying any data, but it's a huge pain to get a system working again from that. Only done it twice; hope never to do so again.

Curious to know how you recover from that? How do you what permissions to assign back to files and directories?

Re: Don't touch my clipboard

#270

Earlier quoted context omitted.

Maybe run `sudo chmod -R 000 /` instead. Can't get charged with destroying any data, but it's a huge pain to get a system working again from that. Only done it twice; hope never to do so again.

Curious to know how you recover from that? How do you what permissions to assign back to files and directories?

Curious to know what circumstances led up to someone doing that and if they were charged for other violations.
Post reply on HN