A partial archive of discourse.wicg.io as of Saturday February 24, 2024.

Invoke paste in JavaScript

AshleyScirra
2017-04-18

We recently launched a game development PWA at https://editor.construct.net.

Like any productivity software, it has clipboard features. Users can cut, copy and paste app-specific content.

However, there’s no way for JS to do a paste. So in our own (DOM-implemented) context menus, we can provide cut and copy options, but not a paste option. Users find this odd (example: https://github.com/Scirra/Construct-3-bugs/issues/96) and it’s a strange quirk of using browser-based software.

Can something like document.execCommand("paste") be standardised?

jhpratt
2017-04-19

Given that AJAX exists, my intuition tells me this is a major security risk. Hopefully others can refute this, but it just seems too “invasive” to me.

DanielHerr
2017-04-19

It is not a privacy concern if it is put behind a permission prompt. And adding this as a web api would actually be less invasive than requiring installing an extension. (See https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Interact_with_the_clipboard#Reading_from_the_clipboard)

DanielHerr
2017-04-19

However, this should probably wait for the async clipboard api instead of using execCommand.

Garbee
2017-04-19

Even if it is behind a permission prompt this could be too valuable of an API to obtain secrets from. For example, password managers that use the clipboard or software looking for secret key pastes and copying the data to send out.

While a permission prompt would handle initial acceptance, it doesn’t provide any context as to when it is being used elsewhere and why. Users also shouldn’t need to be asked every time an API gets used. Probably best this not be introduced.

AshleyScirra
2017-04-19

Could APIs like this not be reserved for “add to homescreen/desktop” apps running in “standalone” mode? That ought to mitigate some of the drive-by information stealing concerns, and a serious productivity app where users will want to be able to paste is relatively likely to be running in that context.

Garbee
2017-04-19

APIs shouldn’t be restricted to the context in which the browser is displaying the site or app. Standalone modes are a UX enhancement for things a user often visits. That shouldn’t then provide extra APIs. It may lead to developers gaming users into forcing those modes for their malicious applications.

An “auto-paste” API is simply a massive privacy and security issue. Extremely too powerful with no proper way to mitigate the pitfalls without a confirmation every time it gets used (which defeats the point and annoys users.)

DanielHerr
2017-04-19

A single persistent permission prompt for web pasting would not be worse than the existing prompt to install an extension. Adding a web paste api would even be a security improvement since extensions can access the clipboard contents in the background whenever they want to, whereas a web api should probably be restricted to the foreground.

AshleyScirra
2017-04-20

Yeah, if you tell users to install an extension you can give yourself powers to snoop on their clipboard even on other websites.

I brought up the “add to homescreen” aspect because Chrome is already making some modifications to web APIs in this mode - for example lifting the “touch to play” restriction on media. So there is in fact precedence for web APIs to work differently in alternative modes like that.