Can't Write to Clipboard (Possibly Linux-related)
gazugafan opened this issue · 13 comments
I've gotten a couple bug reports on my VS Code extension that uses Clipboardy. It seems that there's sometimes a problem calling clipboardy.write(). I haven't been able to reproduce it myself, but both users are running Linux. One in particular is running: Linux x64 4.9.0-8-amd64 (SolydX 9 / Debian Stretch)
One of them gave the following error log...
[Extension Host] Error pasting... TypeError: Cannot read property 'end' of undefined
at handleInput (/home/sembiance/.vscode/extensions/gazugafan.vscode-indent-on-paste-2.3.2/node_modules/execa/index.js:75:17)
at module.exports (/home/sembiance/.vscode/extensions/gazugafan.vscode-indent-on-paste-2.3.2/node_modules/execa/index.js:273:2)
at Object.copy (/home/sembiance/.vscode/extensions/gazugafan.vscode-indent-on-paste-2.3.2/node_modules/clipboardy/lib/linux.js:17:10)
at Object.exports.write.input [as write] (/home/sembiance/.vscode/extensions/gazugafan.vscode-indent-on-paste-2.3.2/node_modules/clipboardy/index.js:28:20)
at indentOnPaste (/home/sembiance/.vscode/extensions/gazugafan.vscode-indent-on-paste-2.3.2/out/src/extension.js:96:24)
... the line in my extension triggering this error (out/src/extension.js:96:24) is calling clipboardy.write(). It looks like this...
clipboardy.write(clipboard_1).then(function () {
...
}, function () { pasting = false; });
... which seems to be really straightforward to me. Not sure what's going wrong, but according to the error log it could be up in clipboardy or execa. Any ideas? Are there any known issues with clipboardy on certain flavors of Linux?
IssueHunt Summary
stroncium has been rewarded.
Sponsors (Total: $40.00)
issuehunt ($40.00)
Tips
- Checkout the Issuehunt explorer to discover more funded issues.
- Need some help from other developers? Add your repositories on IssueHunt to raise funds.
Original bug report in my extension, just for context...
gazugafan/vscode-indent-on-paste#3
The other bug reporter mentioned that his OS is Linux x64 4.20.6 (Gentoo).
Seems to be some problem with reading the stdout stream. Possibly an Electron issue or difference with Node.js. Hard to say for sure without the ability to reproduce it.
@jdall @Sembiance can you offer any more info to help reproduce the issue?
Sure, @gazugafan - if you can tell me what you need, and how to produce it. You know your plugin, and the ecosystem it is installed in. I'm a mere user, knowing nothing about either.
These days, it's so easy to run OS's virtualised. May I suggest that you install VirtualBox and deploy Gentoo or SolydX 9 (the latter is probably the easiest to get started with for a Windows user).
I would be glad to help, but some guidance is needed.
@sindresorhus any chance you can try (or already did try) reproducing this on Gentoo or SolydX? I can certainly try myself, but even if I'm successful I'm not sure what else I could do besides give you the same error log. Do you think we should report this issue somewhere else?
@IssueHunt has funded $40.00 to this issue.
- Submit pull request via IssueHunt to receive this reward.
- Want to contribute? Chip in to this issue via IssueHunt.
- Checkout the IssueHunt Issue Explorer to see more funded issues.
- Need help from developers? Add your repository on IssueHunt to raise funds.
@gazugafan When #50 and sindresorhus/execa#212 get released, it will allow you to see the root error.
Until it didn't happen: either you changed permissions on fallback binary fallbacks/linux/xsel or vscode did it for you. If it is the former, fix your distribution to have execution permission on this binary. If it is the latter, it would probably be a good idea to file a bug report against vscode, but in the meantime, you can check execution permission on extension start and change it if needed.
@gazugafan BTW, if it is a problem vscode introduces, not your packaging, please tell us, it might make sense to introduce handling of such condition right in library, as it should only require a couple of code lines.
Thanks @stroncium !! Yeah you were definitely on the right track. I was packaging the extension on Windows, so your question about executable permissions on the xsel binary made me raise an eyebrow. Turns out, packaging under Windows would remove any executable permissions. I just had to package the extension under Linux to make sure the execute permission sticks. I think that's going to solve it :D
I've just released a new version which I think is going to solve this for the users that originally reported the problem. As soon as I hear back from them, I'm pretty sure I'll be closing this.
We're good. Thanks again!
@sindresorhus has rewarded $36.00 to @stroncium. See it on IssueHunt
- 💰 Total deposit: $40.00
- 🎉 Repository reward(0%): $0.00
- 🔧 Service fee(10%): $4.00