wails: `ClipboardSetText` successfully called, but actually failed
Description
On Macbook M1 Pro, after building, the ClipboardSetText is called. The feedback is successful, but the actual clipboard is empty
To Reproduce
ClipboardSetText(str).then(()=>{
console.log('success')
}).catch((err)=>{
console.err('fail',err)
})
Expected behaviour
It should be possible to paste directly
Screenshots
No response
Attempted Fixes
No response
System Details
# System
OS | MacOS
Version | 13.2.1
Go Version | go1.18.10
Platform | darwin
Architecture | arm64
# Wails
Version | v2.4.1
# Dependencies
Dependency | Package Name | Status | Version
Xcode command line tools | N/A | Installed | 2396
npm | N/A | Installed | 8.1.2
*Xcode | N/A | Installed | 14.2 (14C18)
*upx | N/A | Available |
*nsis | N/A | Available |
* - Optional Dependency
Additional context
No response
About this issue
- Original URL
- State: open
- Created a year ago
- Comments: 15 (6 by maintainers)
This would make an ideal v3 plugin
Hey, I tested out the main branch and it does indeed work.
BUT… there is a potential bug/unintended functionality regarding osascript that was breaking the clipboard for me.
I was using osascript with a prompt, kind of like this
The problem that was occurring is that the GUI prompt which let’s you insert your username/password is grabbing the stdin/TTY (which is used by the clipboard to deliver text) and it was not returning it to the binary being executed by the osascript.
This lead me to abandon the osascript path and instead writing a C file that uses the macos internal Security Framework to generate admin credentials.
I will make the C code available via a git repository tomorrow if you want to use it in order to enable users to launch wails.io apps as administrator with a GUI prompt.
The main culprit for no data being returned is probably the pasteboard* daemon dying (see: [3]). If that daemon dies and set and gets/copies + pasts won’t work properly. And even if the daemon comes back up the app will maybe need to be completely restarted. (*pasteboard is what Apple calls a clipboard)
Inconsistencies could also be due to how
pbpasteworks when there are multiple items in various formats stored in the clipboard. All the wails implementations are using the system’s general pasteboard either implicitly or explicitly in wails v2 or wails v3 respectively.In wails v2…(see: [5])
The
pbcopycommand is called directly via exec and piped input over stdin putting whatever text is given into the general pasteboard.The
pbpastecommand is called the same way and the output from stdout is returned. However, no additional options forpbpasteare used. If you look at the manpage forpbpasteyou’ll notice-Preferas an option.This option is not used explicitly in the wails v2 implementation. However, the reason this option exists is because a pasteboard can have multiple types of data stored in it (see: [7, 8]).
pbpastewill check the pasteboard for a representation of each of these types of data. If none are present it will return nothing.And in general there are other known problems (see: [4]) with getting back rich text as rich text.
TL;DR It’s possible that…
In wails v3… I refer you to the implementation in [6] using the information from above
Refs:
There is
cmd+vin the packaged program menu.Everything is normal in
wails dev, butwails buildis packaged and it prompts that the copy is successful, but the actualcmd+vdoes not have any data