Tk Source Code

The Tk clipboard commands seem to update the clipboard in some way that is invisible to clipboard managers on Mac OS. To be more precise, the first time Tk sets the clipboard, clipboard managers notice it, but all subsequent times, they don't. (See below for reproduction)

I do not think this is a bug in the clipboard managers, since I can see this behavior with not just my clipboard manager (Maccy), but also a more low-level program designed for debugging clipboard issues (Pasteboard Viewer, see the "simpler reproduction" below).

I originally experienced this bug with gitk. gitk sets the clipboard by simply running clipboard clear; clipboard append new_clipboard_contents. If this is wrong, it's a bug in gitk, let me know.

I tested this with tk 9.0.1 and tk 8.6.16, both installed via Homebrew, as well as tk 8.6.15 installed from nixpkgs. I'm using MacOS Sonoma 14.7.6 on ARM.

I am not a macOS expert, I just use it :). The author of Maccy is; perhaps he will reply if you comment on https://github.com/p0deje/Maccy/issues/1100.

Reproduction

I'm assuming that you have Homebrew installed (though you can also reproduce this with Nix, or likely see the same thing if you adapt the steps to some other setup).

After reproducing, it might help to see how Maccy and/or Pasteboard viewer interact with a normal Mac app by e.g. right-clicking on various links in Firefox and selecting "Copy link to clipboard", and observing Maccy or Pasteboard viewer.

Original reproduction with Maccy and gitk

• Install maccy with brew install maccy (it's free) and gitk with brew install git-gui. At the moment, Homebrew's gitk uses Tcl/Tk 8.6.16.

• Follow the "Steps to reproduce" from https://github.com/p0deje/Maccy/issues/1100#issue-3085037371.

Simpler reproduction

• Install https://github.com/sindresorhus/Pasteboard-Viewer from https://apps.apple.com/us/app/pasteboard-viewer/id1499215709.

• Install wish with brew install tcl-tk (installs 9.0.1). (You can also do brew install tcl-tk@8). Start Pasteboard Viewer.

• Open wish. For Homebrew, wish would start Tk 9 (if you installed it; make sure that which wish points to Homebrew. The PATH can also point to a broken Apple-installed wish that doesn't even work on my machine), and /opt/homebrew/opt/tcl-tk@8/bin/wish starts Tk 8.

• Monitor the Pasteboard Viewer as you run something like

clipboard append aa; # Pasteboard viewer usually shows this immediately
clipboard append bb; # Pasteboard viewer still shows `aa`
clipboard get;       # Will show `aabb`
clipboard clear
clipboard append cc

In my experience, the first of these (adding aa) is shown immediately. The rest aren't shown in Pasteboard viewer, though you can check that the clipboard got updated by running clipboard get or pasting into any application.

(You can get the Pasteboard Viewer to update by interacting with it and e.g. switching between the hex view and the text view. However, it's supposed to update without any interaction, as you can test out with non-Tk mac apps)

The other question that's unclear to me is whether there's any downsides to doing clipboard flush automatically after clipboard clear or clipboard append, instead of adding a new command.

As a quick test,

clipboard clear
clipboard append blah; clipboard flush
clipboard append bleh; clipboard flush

works as expected. (As I said previously, clipboard clear; clipborad flush does not quite currently work as expected, but that's a separate issue; it doesn't mess up subsequent clipboard append-s in any way).

This is a bit of a fraught decision, since I don't know how to prove that no Tk program relies on the old behavior. It's hard for me to imagine why they would intend it, and I imagine most would benefit from this change. Still, programs could rely on the old behavior in some way or for some reason I haven't imagined.

Thank you!

I did manage to compile your branch (following the instructions for building Wish.app), and it seems to work at a first glance. In particular, clipboard clear; clipboard append something; clipboard flush works great, every time, even if you run it several times in a row while changing the something.

I found one minor bug: if you run clipboard clear; clipboard flush, the clipboard manager does not detect that the clipboard became empty.

Re your long post

The post is mostly great, but there is one point that seems slightly off. (Unfortunately, I guess there is no way to edit comments?)

So appends to the Tk clipboard, except for the first append after a clear command, will not be visible to a clipboard manager which uses this strategy.

In my experience, only the first append after the first clear command is visible to Pasteboard Viewer/Maccy. If this quote were correct, and the first clipboard append after every clipboard clear worked reliably, gitk would not have a problem. It always runs clipboard clear before every clipboard append.

Again, what actually happens is that only the first clipboard append after another program copied something to the clipboard is visible to clipboard managers. This is consistent with everything else you say in your post AFAICT, and your fix addresses this fine.

Aside on how other tools seem to work

I also played with Firefox a bit more. I opened about:about, then opened the developer tools, and tried running the following in the JS console:

await navigator.clipboard.writeText("aa")
await navigator.clipboard.writeText("bb")

The clipboard manager picked up both changes immediately. I have no idea whether Firefox is doing the same thing you are suggesting, or something else.

gitk does not need to explicitly interact with a clipboard manager. However, it would be more convenient to use with a clipboard manager if that worked like it does with every other program.

Specifically, gitk has a command to copy the current commit's description to the clipboard, and it has an option where clicking on each commit results in copying the commit id to the clipboard automatically.

The latter mode is inconvenient without a clipboard manager (or while gitk doesn't interact well with clipboard managers), since without a clipboard manager, copying to the clipboard is a destructive operation.

Also, when talking about several commits, it's convenient to use the command to copy a commit's description several times in a row (on several commits), without switching to any other window. Then, you can (say) switch to the window where you are writing an email and paste all of these descriptions as you are writing about them, one after another.

There is probably some room for gitk to offer a more convenient interface here, but a clipboard manager really helps with the current interface.

Aside regarding password managers: You may know this already, but there are features to prevent clipboard managers from capturing passwords, but they are imperfect. For example, Bitwarden'd macOS desktop client supports this feature, but the browser extension currently does not. I'm not sure whether something similar exists on Windows/Linux; I think something does exist, but it's a different API.

I, personally, don't find it a huge hassle to manually remove the passwords from the clipboard manager's history, but it's certainly something to be aware of.

Thank you again for looking into it!

Again, I'm not an expert, but you diagnosis seems reasonable to me.

I can't judge why Tk behaves the way it does, and I'm not sure about the best course of action. Two naive thoughts:

• Is it possible to copy the value lazily but then somehow explicitly update the changeCount counter?

• I'm not sure about the privacy advantages of lazy copying. It might mean that a clipboard manager or another program that wanted to snoop couldn't be very efficient, but I would guess it could still check the clipboard's value every X seconds (without consulting the changeCount), if it cared about the snooping more than it cared about efficiency.

I'm not sure whether there are other reasons for lazy copying or what other changes in behavior that would occur if copying became strict.

My first guess would be that strict vs lazy copying would mainly make a difference when copying large amount of data into the clipboard. I did not test how pbcopy or Firefox or other Mac OS apps are supposed to behave when doing so. Perhaps Apple mentions something about that in their docs. The usecase I had in mind (gitk) never copies large amounts of data with clipboard append.

I may have found some clues about this.

The internet says that there is no way to get notification when an item is added to the general NSPasteBoard. The only way to handle this seems to be to poll the pasteboard at some time interval to see whether the value of its changeCount has changed. I will assume that this is what your clipboard managers do. Moreover, the internet suggests that not providing a notification was an intentional decision on Apple's part.

The Apple documentation says "The change count subsequently increments each time the pasteboard ownership changes." That does not mean that the changeCount will be incremented if the string value of the first item on the pasteBoard changes. Especially given that it is allowed for the string value of an item on the pasteBoard to be provided lazily. And it appears that is what Tk is doing.

The function TkSelUpdateClipboard does this:

changeCount = [pb addTypes:[NSArray arrayWithObject:NSStringPboardType]
                      owner:NSApp];

The TKApplication subclass of NSApplication has a method tkProvidePasteboard which appears to be the function that the NSPasteBoard calls when it needs to know the value of a string item which Tk has placed on the pasteboard.

In your example, I am guessing, the first call to "clipboard append" makes Tk's NSApplication object become the owner of the clipboard. The second append changes the value of the first item on the clipboard, which is only known to Tk since it is being provided lazily, and does not change the owner of the clipboard, which remains set to Tk's TKApplicaton. if the ownership does not change and the actual string value is not known to the NSPasteBoard then it makes sense that a password manager which is watching the changeCount of the NSPasteboard will not be aware that anything has changed.

The owner is allowed to be nil. According to Apple, when the owner is nil the the value of the first item on the NSPasteBoard must be provided immediately. Here is an example from the Chrome browser, which uses the general NSPasteBoard that way:

void Clipboard::WriteText(const char* text_data, size_t text_len) {
  std::string text_str(text_data, text_len);
  NSString *text = base::SysUTF8ToNSString(text_str);
  NSPasteboard* pb = GetPasteboard();
  [pb addTypes:[NSArray arrayWithObject:NSStringPboardType] owner:nil];
  [pb setString:text forType:NSStringPboardType];
}

The call to the addTypes method, with nil owner, is immediately followed by a call to the setString method.

It seems likely that changing from providing the string value lazily to providing it immediately would "fix" the behavior being reported in this ticket. However, that is not a trivial change, and it may be unwise to "fix" it.

Experience suggests that Tk design decisions, like whether to provide clipboard string values lazily, were usually made for a reason. Changing a basic part of the design almost always breaks things. Experience also suggests that it will be difficult to predict in advance which things will break. After that is finally known, the question remains whether the broken things were more important than making sure that a random clipboard manager is notified whenever Tk puts anything on its clipboard.

I know of one particular context where not notifying other apps that the clipboard has changed is a very important positive feature. That is for a Tk based password manager. Many password managers allow copying the password to the clipboard so that the user can then paste it into a web browser. That operation is a lot safer if it is not possible for some other app that happens to be running on the same computer to record everything which gets placed on the clipboard.

I think it is quite likely that this sort of privacy issue was what was behind the choice to provide values for clipboard strings lazily. Perhaps changing terminology from "clipboard manager" to "clipboard snooper" would help to view this issue from a better perspective.

Thank you!

As I mentioned before, the minimal C example from https://nathancraddock.com/blog/writing-to-the-clipboard-the-hard-way/ and https://github.com/natecraddock/sandbox/tree/main/objc seem to work fine too. However, they set the clipboard, they don't do clipboard append.

The pasting is not the problem, the correct info is getting pasted either way.

The difference is in when or whether a clipboard manager (or Pasteboard viewer) detect that the clipboard changed. When I copy from Firefox or when I use pbcopy to copy from the terminal, both the clipboard manager and the Pasteboard viewer get updated immediately without further interaction. When I copy using clipboard append, this does not happen.

So, I can't be 100% sure that Pasteboard Viewer or Maccy (the clipboard manager) are bug-free, but I'm 100% sure that clipboard append copies the text in a way that interacts worse with them compared to the way pbcopy copies text.

Unfortunately, this does also mean that I don't know a good way to detect the problem without these tools, since I don't understand what the difference is.

A workaround is to use pbcopy, which doesn't have this problem. Example: https://github.com/j6t/gitk/pull/19.

For reference, I found a seemingly very nice and minimal implementation of copying to clipboard on a Mac in C or objective C here:

https://nathancraddock.com/blog/writing-to-the-clipboard-the-hard-way/#fnref3

https://github.com/natecraddock/sandbox/tree/main/objc

This implementation seems to work fine with Maccy or Pasteboard Viewer. To test it, I just followed the first set of instructions in the README (which use lua).

Its one downside is that this example implements a "clipboard set" function, while Tk seems to need an "clipboard append" function.