search

wailsapp / wails

Create beautiful applications using Go
https://wails.io
MIT License
25.47k stars 1.23k forks source link

`ClipboardSetText` successfully called, but actually failed #2534

Closed Licoy closed 1 day ago

Licoy commented 1 year ago

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

leaanthony commented 1 year ago

If you don't have paste in your menu with a cmd-v accelerator, you won't be able to paste

Licoy commented 1 year ago

image

There is cmd+v in the packaged program menu.

Everything is normal in wails dev, but wails build is packaged and it prompts that the copy is successful, but the actual cmd+v does not have any data

CiroLee commented 1 year ago

I encountered the same problem, using the api provided by wails, the dev mode is able to copy and paste, after the build, sometimes you can paste, sometimes not, it is puzzling

zveinn commented 1 year ago

Can confirm this issue still exists, copy and paste commands are visible in the toolbar menu. Paste always returns and empty text and copy does not seem to work at all. Old clipboard values are still present after copy.

The copy and paste functions seem to work as intended when running wails in development mode.

ethanwillis commented 1 year ago

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 pbpaste works 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 pbcopy command is called directly via exec and piped input over stdin putting whatever text is given into the general pasteboard.

The pbpaste command is called the same way and the output from stdout is returned. However, no additional options for pbpaste are used. If you look at the manpage for pbpaste you'll notice -Prefer as 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]). pbpaste will 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:

  1. man pbpaste
  2. man pbcopy
  3. restarting pboard daemon + apps
  4. rich text coming out of pasteboard as plain text
  5. wails v2 darwin clipboard implementation
  6. wails v3 darwin clipboard implementation
  7. Apple Pasteboard overview
  8. Apple Pasteboard programmer guide
zveinn commented 1 year ago

It still seems kind of strange that the clipboard would work just fine when running "wails dev" but then breaks on the same text once the app is built. Maybe there are some implementation details that differ between the actual build and the dev environment ?

leaanthony commented 1 year ago

Yeah the v3 API was changed from get/set to explicitly gettext/settext for this reason. Im assuming nothing can be done for Linux as there's no standard API for it?

leaanthony commented 1 year ago

It still seems kind of strange that the clipboard would work just fine when running "wails dev" but then breaks on the same text once the app is built. Maybe there are some implementation details that differ between the actual build and the dev environment ?

Odd. The only platform that may exhibit this behaviour is macOS as the plist can often affect functionality

zveinn commented 1 year ago

I tried using the same .plist file for production and dev but no dice.

It seems like there is a long running bug on webkit: https://bugs.webkit.org/show_bug.cgi?id=75891 Here is a stackoverflow thread talking about some possible fixes: https://stackoverflow.com/questions/29376510/custom-cut-copy-paste-operations-for-wkwebview This thread references the copy/paste javascript events inside webkit as a possible workaround: https://developer.apple.com/library/archive/documentation/AppleApplications/Conceptual/SafariJSProgTopics/CopyAndPaste.html

The only NS tag I could find related to data sharing between apps was this one: NSAppDataUsageDescription But it seems to be linked with sharing data between non-apple apps so I doubt it's what we are looking for, figured I'd mention it anyways, just in case.

zveinn commented 1 year ago

I just noticed something else.. the entire "right click" context menu is disabled after building but works during dev runs.

Maybe there is some code that runs during production builds that is trying to intercept/overwrite/modify the context menu that's causing the context menu to break, which would then cause copy/paste to not work, since it's most likely tied to the context menu

@leaanthony

leaanthony commented 1 year ago

Master now has the fixes for this. Please test using this guide.

zveinn commented 1 year ago

I will give it a go once my coffee kicks in, thanks !

zveinn commented 1 year ago

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 

osascript -e 'do shell script "./NicelandVPN" with prompt "Run NicelandVPN as admin" with administrator privileges'

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.

leaanthony commented 1 year ago

This would make an ideal v3 plugin

zveinn commented 1 year ago

@leaanthony here you go: https://github.com/zveinn/macos-app-builder There are scripts in their for codesigning, notarization, icon generation.

the launcher.c is the automatice launcher code. But there is a pre-built binary already inside the MacOS folder.

P.s. the authorization methods being used are marked as deprecated by apple, but they probably aren't going away anytime soon since a lot of apps depend on them.

I also made a youtube monstrosity: https://www.youtube.com/watch?v=4tZpcz15PXI

timmattison commented 3 months ago

Can you repost the video? It is unavailable on YouTube now.

leaanthony commented 1 day ago

Looks like this can be closed now.