Copy/Paste Support in WebShell
I recently ran into issues with copy/paste support in WebShell. Here’s a summary.
Browser Clipboard Permissions
When clipboard permissions are disabled, using the Clipboard API throws errors. Some users’ browsers restrict clipboard access for security. Can WebShell still support copy/paste? Yes—browsers also have default copy and paste hotkeys.
Browser Copy/Paste
On Windows, copy is Ctrl+C
, paste is Ctrl+V
.
On macOS, copy is Cmd+C
, paste is Cmd+V
.
These hotkeys are fixed; pressing them triggers the corresponding default behavior.
However, page logic can intercept and prevent the default behavior, which can cause issues—for example, with xterm.js on Windows.
Ctrl+C/Ctrl+V in xterm.js
xterm.js listens for and handles key events, which can prevent these hotkeys from working. How to fix this?
Use attachCustomKeyEventHandler
to handle hotkeys and return false
so the default behavior continues.
customKeyEventHandler – The custom KeyboardEvent handler to attach. This is a function that takes a KeyboardEvent, allowing consumers to stop propagation and/or prevent the default action. The function returns whether the event should be processed by xterm.js.
attachCustomKeyEventHandler(customKeyEventHandler: (event: KeyboardEvent) => boolean): void;
Browser hotkeys can’t fully replace the Clipboard API. When clipboard is unavailable, can we still implement copy/paste?
The answer is: partially.
document.execCommand(‘copy’)
The document’s execCommand
method supports copy. In testing, even without Clipboard API, you can dynamically copy specific text to the clipboard.
Paste isn’t supported (IE reportedly supports it). Note that this API is deprecated and considered legacy. Still, as a fallback for copy, it’s a reasonable option.
Final Thoughts
That’s pretty much it for copy/paste.
In summary, when Clipboard API access is unavailable, you can still rely on the browser’s default hotkeys for basic text copy/paste—just make sure you don’t block the default behavior.
done.