-
Notifications
You must be signed in to change notification settings - Fork 321
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Discussion: What do you want in a better clipboard API for Windows? #63
Comments
Synchronization of the clipboard between phone and windows devices would be nice! |
We actually have that now! It only works with Samsung Android phones for now, though. If this feature were available to more phones and/or more Windows devices, how might you imagine programming it? |
Clipboard APIs today (wall of text follows)For your reference, here's the current state of the Windows clipboard API from a very high level. As we look to craft a potential Project Reunion API for clipboard, we'd want to figure out both how to help you avoid traps that the current API presents and how to give you new features you could use to make your users happier. There are 3 basic API surfaces for interacting with the Windows clipboard:
All 3 APIs are equivalent in basic clipboard functions, but Windows.ApplicationModel.DataTransfer also recently added programmatic access to the clipboard history and cloud-roamed clipboard data, as part of the addition of those features in the November 2018 update to Windows (Windows 10 version 1809). All 3 APIs have their own advantages and pitfalls - as alluded to above, both the OLE data transfer API and Windows.ApplicationModel.DataTransfer potentially make it too easy for copied data to disappear from the clipboard when source apps are closed, frustrating users when they try to paste text from their web browser or email program and getting nothing instead, or a previously copied item they no longer want. |
I just want my copy and paste actions to work every time, without fail, and without complication |
I just want my copy and paste actions to work every time, without fail, and without complication
In our observation at Microsoft, a lot of problems with clipboard reliability are caused by apps that use the clipboard APIs in the "wrong" way. For example:
- The classic clipboard API allows any app that is reading or writing clipboard data to accidentally lock out all other apps from accessing the clipboard - to do that, you can just forget to call CloseClipboard() when you're done. The most obvious symptom of this is a Paste operation pasting an older image or piece of text, as the most recent cut or copy attempt had silently failed due to the clipboard lockout.
- As I noted above, the OLE data transfer API and Windows.ApplicationModel.DataTransfer require an explicit "flush clipboard" step. If a source app for copied clipboard data forgets to flush its written data values, they could be lost when the app exits, leading to no data being pasted on paste attempts.
To get to 100% clipboard reliability, we'll need to figure out how to fix our mistakes that have led people down the wrong paths. That's part of the reason I started this discussion - we'd like to learn how to make it easy for people to do the right thing and how to make it hard or impossible for them to do the wrong thing.
|
I don't know about the feasibility / effort required of different options, but would it be possible to have a Roslyn Analyzer for that to point at mistakes in the use of these APIs (as a short term helper)? I can imagine that changing the APIs themselves could be a longer-term project. |
That's an interesting idea. From my understanding, Roslyn analyzers in particular only work for C# and VB, but other .NET managed code languages, as well as native code, could benefit from similar static analysis. I don't think we at Microsoft have really used static code analysis in Windows native code development for cases other than "this could be a security vulnerability", but perhaps we should consider broadening our view... |
I really want an API that allows classic & UWP app to set data it sends to the clipboard as "private." This will be useful for password manager apps, where I copy the password in the clipboard and then paste it into a web browser or other app. Currently, this goes right into the clipboard history and is then promptly synced on other devices. I do not want my passwords in the clipboard history for the simple reason that somebody with access to the computer could press Win-V and view passwords I used in the past. |
There are already 2 ways to prevent newly set clipboard data values from being synchronized by cloud clipboard or entered into the local clipboard history:
Are neither of those options working for you? |
I wasn't aware of those APIs, I just based off my assumption on the behavior of my current password manager. I'll go bother them with this then 😅 |
For privacy reasons, I think that every (approved) access to the clipboard should trigger the appearance of an icon in the taskbar (just like with geolocation access). An extra step that I would also like to see for all these sensitive services is that there should be a way to see a history of these accesses after the fact. That way, we can audit apps to confirm that they did not abusing these services while we were distracted. |
There's also Pushbullet (off topic but it's worth mentioning alternatives to Your Phone, which is quite limited in the devices it supports) |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
One part of Windows we at Microsoft (myself, @ShawnSteele, and some others) have been thinking of evolving as part of Project Reunion is the API for the Windows clipboard.
We've already seen a great idea for a clipboard improvement in issue #62 - allowing apps that were previously prohibited from accessing the clipboard in the background to do so when responding to a toast notification. As we think about whether and how to decouple the clipboard API and implementation into the eventual Project Reunion codebase, we'd like to hear some more ideas.
So, if you have pain points or improvement ideas for the clipboard that aren't quite fleshed out enough for an issue of their own, feel free to post them here! We'll try to keep up and listen, and may spin off issues for ideas as they get refined.
Related Links
#62 #67
The text was updated successfully, but these errors were encountered: