This is just a naive attempt to fix Windows Clipboard

[lkishalmi]

I do not have a chance to test this. It is just for supporting a mail on the dev list.

This is removing the Windows OS specific code from NbClipboard, that might cause copy+paste loss between other application and NetBeans.

There is a bug mentioned in the code. That was supposed to be fixed in Java 6. So let's hope this would not cause any harm.

Anyway, I'd propose to include this PR on master, so more people can test it, especially in the NB16 RC phase. This is simple enough to get reverted if something goes south.

This change is not guaranteed to make anything better.

[eirikbakke]

Great to see work on this! I still see this problem about once or twice a month.

Let me take a closer look at this in a few days. I can include this patch in my local IDE build and use it for a while. (I would probably need to test it on my working IDE for 3 months before concluding that the bug is really gone, since the problem is rather infrequent.)

[eirikbakke]

There is a bug mentioned in the code. That was supposed to be fixed in Java 6. So let's hope this would not cause any harm.

I'm not so sure. The "resolved" status for the mentioned JDK bug is from 2005, but the workaround that is removed in this PR dates back to 2014. We don't have any indication that the problem that was worked around in 2014 was solved in JDK after that.

So this patch might risk introducing the 2014 bug.

But I can still try it in my working IDE, and see if the newer clipboard bug reappears. If it does, even once, then at least we can eliminate this particular piece of code as the culprit.

[lkishalmi]

@eirikbakke you could also try to run the stock IDE with-J-Dnetbeans.slow.system.clipboard.hack=false or -J-DTopSecurityManager.disable=true the first one only disables the hack on the NBClipboard the second one does not use the NbClipboard at all.

I'm on Linux, so I do not supper form the issue, though I'm running my IDE with both of those options, and it seems with JDK 17 at least NetBeans does not need a special Clipboard to work flawlessly.

[eirikbakke]

OK, I'll try "-J-Dnetbeans.slow.system.clipboard.hack=false" first.

Why could "-J-DTopSecurityManager.disable=true" matter here?

[neilcsmith-net]

Why could "-J-DTopSecurityManager.disable=true" matter here?

@eirikbakke It seems to be the only way to disable all of the NetBeans specific clipboard functionality currently.

[eirikbakke]

@neilcsmith-net Ah, I found that piece of code in TopSecurityManager.makeSwingUseSpecialClipboard. I think I'll try just disabling that specific hack for now, and see if it causes any problems, since that is useful to know for #3386 as well. Then if I encounter the clipboard bug again over the next few months, I'll try setting netbeans.slow.system.clipboard.hack=false...

[eirikbakke]

OK, that was quick... this morning I started using my new custom NetBeans 15 build with the makeSwingUseSpecialClipboard hack specifically disabled, and I already see one instance of the clipboard bug appearing. So makeSwingUseSpecialClipboard
was not the problem.

Some observations about the bug as I observed it just now:

• I'm on Windows 11, running Zulu OpenJDK 17.0.2 and a custom build of NetBeans 15.0
• After copying a string from jEdit, another Java app, I am not able to paste it into NetBeans, despite it pasting fine into Windows 11 Notepad.
• Once NetBeans is in this state, copy/paste with external applications appears permanently broken until NetBeans is restarted.
• Copying another string from Notepad also cannot be pasted into NetBeans.
• NetBeans can still copy/paste strings within itself, but also cannot copy strings back to Notepad. Copying a string in NetBeans does appear to clear contents of the clipboard that was created by Notepad, however.
• Copy/paste between other Windows applications (not NetBeans) still appears to be working.
• Other apps running at the time the bug was observed: Adobe Acrobat Professional, Microsoft Excel, jEdit on Java 10.0.2 (different JDK than NetBeans), Windows Command Prompt, Chrome, WSL Ubuntu, Windows Explorer, a production and development version of a NetBeans Platform application (on Java 17.0.3), Microsoft Outlook.

Next, I'll start using netbeans.slow.system.clipboard.hack=false in my working IDE and see if the bug still appears at some point.

[eirikbakke]

OK, about 5 hours of IDE work later, the bug appears again, this time with netbeans.slow.system.clipboard.hack disabled, too, as well as the makeSwingUseSpecialClipboard hack disabled like before. So neither of those settings fix the bug. It also seems this bug is much more frequent than I realized before... twice a day rather than once every few months. I only now started to make mental note of it every time it happened.

This time I noticed it trying to copy something out of NetBeans and into Excel, and then into Notepad. But once the bug appears, the clipboard stays broken in both directions (in and out of NetBeans), and I have to restart the IDE to reset it.

My next step will be to try the patch in this PR. I'll have to make another NetBeans build first...

[lkishalmi]

Try with -J-DTopSecurityManager.disable=true only. That entirely disables our custom Clipboard. Other mentioned switches won't matter at all form that point. (not even the loglevel increase)

[eirikbakke]

While leaving the IDE in the broken clipboard state, I ran the following code from the IDE (which ends up in a subprocess):

// And of course I had to restart the IDE before I could paste this here...
public static final void main(String args[]) {
  SwingUtilities.invokeLater(() -> {
    Toolkit.getDefaultToolkit().getSystemClipboard().setContents(new StringSelection("hallo!"), null);
  });
}

That works fine, and "hallo!" can be pasted into Notepad. But the IDE parent process remains broken.

[eirikbakke]

Try with -J-DTopSecurityManager.disable=true only. That entirely disables our custom Clipboard. Other mentioned switches won't matter at all form that point. (not even the loglevel increase)

That was the first thing I tried this morning, except rather than disabling the entire TopSecurityManager thing, I specifically disabled TopSecurityManager.makeSwingUseSpecialClipboard (by changing the code). I still saw the bug in this case.

[lkishalmi]

Try with -J-DTopSecurityManager.disable=true only. That entirely disables our custom Clipboard. Other mentioned switches won't matter at all form that point. (not even the loglevel increase)

That was the first thing I tried this morning, except rather than disabling the entire TopSecurityManager thing, I specifically disabled TopSecurityManager.makeSwingUseSpecialClipboard (by changing the code). I still saw the bug in this case.

Oh. that is disappointing. Still would try to disable the whole security manager, maybe that could interfere as well. SecurityManager will go away anyway.

[eirikbakke]

@lkishalmi I'm just going by elimination, so I'm changing as few things as possible with each trial. With the bug appearing much more frequently than I previously thought, I will get to try several things.

My next attempt will be to actually apply the patch in this PR.

[eirikbakke]

Interesting: Setting "-J-DTopSecurityManager.disable=true" seems not to prevent NbClipboard from being used entirely; the code touched by this PR still runs (confirmed via print statements). Various parts of the NetBeans codebase get at it by doing Lookup.getDefault().lookup(ExClipboard.class).

So this means I haven't really eliminated NbClipboard yet from being involved in the bug. I'll try this PR next.

(And I bumped into the bug yet another time today, when still on yesterday's configuration. It's actually quite frequent.)

[eirikbakke]

I think I just hit the bug again, while trying to paste from Excel and into NetBeans, with the patch from this PR applied. Except now the clipboard started working again, before I actually restarted NetBeans. Will keep observing...

(I had 2.5 days without computer work over the weekend, so the frequency is still about the same...)

[eirikbakke]

I just hit the bug again now, in the same open NetBeans session as yesterday (with the patch from this PR included). The bug once again prevented copy/paste between NetBeans and jEdit in either direction. But with the patch from this PR, the bug seems to disappear by itself after a little while, without restarting the IDE. From the time the bug appeared, to the time when the bug disappeared again 2-3 minutes later, I had been Alt+Tabbing between NetBeans and jEdit a few times and trying Copy/Paste between them.

I'll wait for this circumstance to occur again once more, and then I'll deactivate the patch to compare again, in particular to see whether the bug really is permanent (until NetBeans is restarted) when the PR patch is not in place.

[lkishalmi]

@eirikbakke I really appreciate the effort you are putting on this! Thank you Eirik!

[eirikbakke]

No problem! This bug has been bugging me for a long time, too. I'm just using this GitHub issue to record my observations now...

[eirikbakke]

Once more, copying from NetBeans and into an external app (this time the WSL terminal, and then Notepad) stopped working. But then it started working again, after a few attempts. It was only about 60 seconds that it didn't work. I have still not restarted NetBeans.

[eirikbakke]

Same thing again now, some hours later. Copy from NetBeans into jEdit fails at first attempt. But Alt+Tabbing back to NetBeans, and invoking Ctrl+C again to copy makes it work (happened twice in the last 3 minutes). Much less of a problem than before.

[eirikbakke]

For the last 10 days, I've been using an alternative patch that keeps the existing removeFlavorListener/addFlavorListener calls, but calls fireChange() after the addFlavorListener to catch up on any missed updates. So far it seems to work, though I've been traveling and using the IDE less intensively. Will continue observing...

[eirikbakke]

I encountered the problem again with the new version of the patch, but again, as with the original patch, the problem now fixes itself after a couple of Ctrl+C's.

(Today's exact observation was a problem pasting a URL from the Chrome address bar into a comment in Java code in NetBeans. Copying something in NetBeans and then copying from Chrome again cleared the problem.)

[lkishalmi]

@eirikbakke Shall we include this one to NB16? If yes please approve! Even it is not a fix, it is still an improvement.

[eirikbakke]

Sure. Here's the version of the patch I've been using for the latest 12 days:

#4774

The main advantage over the earlier patch is that we avoid removing the workaround for the other old bug.

[swpalmer]

Just a note for something to try. I’ve noticed that when this bug appears, copying something from the NetBeans About dialog seems to work (can be pasted into external application).