Windows clipboard issues discussion

[mbien]

Copying text in and out of NetBeans stops working for some users on windows, this thread discusses #3962 on the adventurous quest to fix the bug.

updates:

• the issue has been reproduced outside of NetBeans which confirmed that it is a JDK bug https://bugs.openjdk.org/browse/JDK-8353950
• JDK patches are available, after discussing various options on the dev list, it was decided to apply the patch via JVM agent until fixed in the JDK itself
• NetBeans 26 RC 1 contains the fix, see Apache NetBeans 26 release candidates #8431 for release candidate testing

thanks to everyone who participated in this endeavor, esp to @xxDark who came up with the initial patch (#7051 (comment)), many community members who helped finding methods to reproduce the race condition more reliably and @matthiasblaesing for integrating it into NetBeans 26 #8361

[stodge]

For me, CTRL+X in Netbeans temporarily restores the broken copy functionality, until it happens again that is.

[gregkotsaftis]

this fixes the issue temporarily.
for NB 25, i have to CTRL+X inside NB editor almost always before copy/paste some text from a web page or from NB to notepad.

[wumpz]

Using Netbeans 23 relaxes most of the problems for me. Most of the time a copy / paste does not work, the second try succeeds. So right direction.

[Chris2011]

I can confirm the problem on Windows and funny thing is, sometimes it works back again. Maybe a raise condition with smth?

[stodge]

Netbeans 23 doesn't seem to improve things for me. It still happens a lot. Occasionally if I try CTRL+C twice it may fix it, but not always.

[jShiwaniGupta]

I can confirm that I’m experiencing this issue as well; it seems to be quite common on Windows. The CTRL+C shortcut often fails to work, which is really frustrating. As a workaround, I’ve been using CTRL+X followed by CTRL+Z to copy text from NetBeans to other applications, but it’s not a reliable solution. Additionally, I’ve noticed that sometimes copying from external apps to the NetBeans editor using CTRL+V also fails, forcing me to open the file in an external editor. I really hope a fix can be implemented soon!

[jGauravGupta]

I completely agree with the frustration expressed in this thread. This clipboard issue is not just frustrating but quite basic and critical for daily workflow. It's concerning that such an essential feature is unreliable, as it may force many developers to switch to other IDEs just to avoid the constant interruptions. A fix for this issue is quite important and would make a huge difference for all of us who rely on NetBeans for efficient development.

[jShiwaniGupta]

I will take a look at NbClipboard.java, as I can only reproduce the issue after working with NetBeans for extended periods.

[eirikbakke]

@jGauravGupta @jShiwaniGupta If either of you have a chance to try it, I'd be curious to hear if the patch posted at #3962 (comment) by any chance fixes the problem.

[jShiwaniGupta]

I downloaded the NetBeans 24 RC1 tag and built it locally for testing. Unfortunately, I was still able to reproduce the clipboard issue. After that, I applied the patch to the NbClipboard and tested it again, but I could still reproduce the problem. It seems that the patch didn't resolve the clipboard issue for my setup.

For testing, I opened the IDE and loaded a Java file, then left it idle for 30-60 minutes. After that, I attempted to copy content from my browser to the IDE, but unfortunately, I was unable to do so.

Edit: I will observe this patch over the next few days to assess if it reduces the overall occurrence of the clipboard issue.

[eirikbakke]

@jShiwaniGupta Thanks a lot for testing! Your report is useful, as it eliminates one (somewhat unlikely) theory I had about the cause of the bug.

[ebresie]

Any logs or profiler dumps available when this happens?

[stodge]

I don’t know if this will help but I typically copy/paste between NetBeans, IntelliJ, Notepad++ and VisualCode. This is on windows 11. I tend to switch apps pretty quickly when I’m copy/pasting but I don’t know if that’s relevant. I also have two external monitors attached to my laptop.

I can’t help with the code but I’ll see if I can build and run from source. Maybe I can quickly try a patched version. I’ve never built NetBeans but if it might help, I can try. I’ll have to check the policy at work on running a patched version though.

[stodge]

I think I can always copy from the Debug output window, and paste it into an external application. So is the problem only related to the main file editor? Or was this fact already known and, as always, I missed it? 😆

[wumpz]

I added a PR to introduce this new retry logic for SetContents as well: #8024.

With this, SetContents and GetContents are equally atomic and do not create new tasks within the executor. With atomic I mean, once it starts processing, it does not create any other tasks but stays within its own thread and holding further processing, till MAX_TRIES is reached or success. The executor has only one thread as a processor.

It is possible that this interference is one reason to break copy and paste in windows, since get and set clipboard could interfere each other. Using this windows hack there always was a GetContens after Netbeans got focus back. I remember using FINE logging for this NbClipboard stuff, I had log messages telling me, that the system clipboard was not reachable. So a collision should be definitely there.

Since there seems to be a timing or threading problem, my guess is that the convert method with all its flavours stuff in it has some complex stuff to do and therefore could take its time. Using this fine logger does a convert again to log out clipboard values. @stodge I cannot confirm, that copy from output window is not affected, but my guess is, that the more complex the editor is I am in, I am copying from, the more likely it becomes a problem.

So having these thoughts, making SetContent and GetContens atomic seems to be the right way to go.

[stodge]

Did #8024 make it into Netbeans 24?

[wumpz]

@stodge Not yet. I am running on it for some time now, but the problem occurs still from time to time. However, I have the "feeling" it is much less than without #8024 and the getContents modifcation. But saying this I am aware that there are very different experiences of this problem from different users.

[stodge]

Thanks, just wanted to confirm.

[niabot]

Netbeans 24: After pasting breaks, copying is also affected. Instead of copying an empty selection (just the cursor), it copies as if the entire line was selected, even if it is (at least visibly) not. Some strange indexing is going on.

[matthiasblaesing]

Netbeans 24: After pasting breaks, copying is also affected. Instead of copying an empty selection (just the cursor), it copies as if the entire line was selected, even if it is (at least visibly) not. Some strange indexing is going on.

That is not a bug, it is a feature. Copy without selection copies current line.

[wumpz]

Any actions here?

[xxDark]

After seeing this on Java's Reddit, I decided to take a look at this (even though I've never used this IDE). I was able to reproduce this issue 100% of the time right from the opening. I've found the root cause and will post a fix once I figure out why this is the case.
In short, AWT is supposed to call lostSelectionOwnershipImpl from the toolkit event loop, but this never happens, leaving cached "contents" in SunClipboard poisoned.
See https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/native/libawt/windows/awt_Toolkit.cpp#L1038 where this should be happening, but it simply doesn't. Either netbeans uses some AWT functions off the event loop thread, making IsGettingOwnership always return true, or something else (overriding WindowProc, etc.)

If one puts a breakpoint here https://github.com/openjdk/jdk/blob/a891630817844c8c42994da3b3110925ca4595a0/src/java.desktop/share/classes/sun/awt/datatransfer/SunClipboard.java#L135 and forcefully sets contents to null, magically, everything will work again.

I added a bit of checking, and indeed, that is what is happening.

Opening clipboard on thread Thread[System clipboard synchronizer,1,system]
Opening clipboard on thread Thread[System clipboard synchronizer,1,system]
Opening clipboard on thread Thread[System clipboard synchronizer,1,system]
Opening clipboard on thread Thread[System clipboard synchronizer,1,system]
Opening clipboard on thread Thread[AWT-EventQueue-0,6,IDE Main]
Opening clipboard on thread Thread[AWT-EventQueue-0,6,IDE Main]
Update clipboard
Opening clipboard on thread Thread[AWT-Windows,6,system]
FATAL ERROR in native method: oooopsie
        at sun.awt.windows.WClipboard.openClipboard0([email protected]/Native Method)
        at sun.awt.windows.WClipboard.openClipboard([email protected]/WClipboard.java:113)
        at sun.awt.windows.WClipboard.handleContentsChanged([email protected]/WClipboard.java:166)
        at sun.awt.windows.WToolkit.eventLoop([email protected]/Native Method)
        at sun.awt.windows.WToolkit.run([email protected]/WToolkit.java:365)
        at java.lang.Thread.run([email protected]/Thread.java:840)

Added check in Java_sun_awt_windows_WClipboard_openClipboard:

	if (AwtClipboard::IsGettingOwnership()) {
		env->FatalError("oooopsie");
	}

Edit: I've narrowed down the cause, and this seems to be a bug in the JDK. I'm getting assert failures building AWT with -DDEBUG.
handleContentsChanged seem to be the culprit.

    private void handleContentsChanged() {
        if (AppContext.getAppContext() == null) {
            handleContentsChanged0();
            return;
        }
        EventQueue.invokeLater(this::handleContentsChanged0);
    }
    
    private void handleContentsChanged0() {
        long[] formats = null;
        try {
            openClipboard(null);
            formats = getClipboardFormats();
        } catch (IllegalStateException exc) {
            // do nothing to handle the exception, call checkChange(null)
        } finally {
            closeClipboard();
        }
        checkChange(formats);
    }

Local fix on my machine, I haven't been able to reproduce the issue with this change. Running AWT tests

[eirikbakke]

There was a "NB 25 Paste from Clipboard Problem Worse?" message on the nbusers mailing list now; I answered it with a link to @xxDark's agent.

Based on the discussion, my own proposal would be the following:

1. Don't wait for an OpenJDK fix. (Rationale: It will take many releases, and we are quickly losing users over the issue.)
2. Do ship a solution with the official NetBeans binaries, not just with community installers. (Rationale: Many users will download the official Apache binaries only.)
3. Use the agent-based approach instead of patch-module. (Rationale: The alternative, of doing patch-module with WClipboard.java, involves legal clearance and external packaging hurdles.)
4. Allow this specific bug to be fixed with an agent even though we may be trying to avoid agents in other, separately discussed, cases. (Rationale: Basic cut-and-paste between applications is exceptionally important, as it is needed by 100% of users. And a single-purpose agent can be removed entirely once the bug is fixed in OpenJDK.)

This of course assumes that someone finds the time to work on it... but it's good to know in advance that a PR that follows this approach would actually get accepted.

[neilcsmith-net]

@eirikbakke I mostly agree, but -

2. Do ship a solution with the official NetBeans binaries, not just with community installers. (Rationale: Many users will download the official Apache binaries only.)

We simply don't know where people will download from with NB26. There will be no "official" Windows installer, or at least no-one is working on what would be required to ship one as far as I know. There will be no macOS installer afaik either. The ASF zip and the community .exe installer have comparable usage stats. The ASF .exe usage is at least an order of magnitude higher.

I guess we'll find out whether people want "official" or they want installers. My concern is that the two options should differ in behaviour and end result as little as possible. That has always been the aim. We should also not conflate official with trusted - some of these are literally built and signed on the same box, by the same person, at the same time!

Another thing to consider if going down the agent route is whether to use asm? eg. https://github.com/apache/netbeans/blob/888df0be86cb8145eec0653729d792b7cfd1ab52/platform/o.n.agent/src/org/netbeans/agent/TrackingAgent.java

[eirikbakke]

The ASF zip and the community .exe installer have comparable usage stats.

I am referring to the ASF zip here. Is anyone opposed to shipping an agent-based patch in the "ASF zip"?

(Not familiar with the technical details of agent development, but yes, we can see if there are ways we can simplify the agent code.)

[neilcsmith-net]

Removing ASM is probably not going to simplify the agent code! However I suspect is the root cause of https://lists.apache.org/thread/tsdbr2r95njpycgf68trxfk9h62jtspv

This shows the issues to consider if using either of these approaches, particularly if in the zip.

We should move this conversation back to dev@ anyway now.

[eirikbakke]

We should move this conversation back to dev@ anyway now.

Sure, I started a thread there ("Adapting xxDark's Clipboard Problem Fix") with a summary of the saga so far.

[johntor]

in version 24 using -J-Dorg.netbeans.NbClipboard.level=FINEST i had very limited problems.
In version 25 clipboard is unusable!!!

I run CopyPasteTest and here are the results

`
Iteration 1: 2025-02-23 16:07:07.627 - Pasted into NetBeans - Error: Copied or pasted text is empty.

Iteration 1: 2025-02-23 16:07:08.557 - Pasted into Notepad

Iteration 2: 2025-02-23 16:07:09.364 - Pasted into NetBeans - Error: Copied or pasted text is empty.

Iteration 2: 2025-02-23 16:07:10.284 - Pasted into Notepad

Iteration 3: 2025-02-23 16:07:11.077 - Pasted into NetBeans - Error: Copied or pasted text is empty.

Iteration 3: 2025-02-23 16:07:11.995 - Pasted into Notepad

Iteration 4: 2025-02-23 16:07:12.788 - Pasted into NetBeans - Error: Copied or pasted text is empty.

Iteration 4: 2025-02-23 16:07:13.709 - Pasted into Notepad

Iteration 5: 2025-02-23 16:07:14.499 - Pasted into NetBeans - Error: Copied or pasted text is empty.

Iteration 5: 2025-02-23 16:07:15.478 - Pasted into Notepad

Iteration 6: 2025-02-23 16:07:16.268 - Pasted into NetBeans - Error: Copied or pasted text is empty.

Iteration 6: 2025-02-23 16:07:17.310 - Pasted into Notepad

Iteration 7: 2025-02-23 16:07:18.100 - Pasted into NetBeans - Error: Copied or pasted text is empty.

Iteration 7: 2025-02-23 16:07:19.144 - Pasted into Notepad

Iteration 8: 2025-02-23 16:07:19.937 - Pasted into NetBeans - Error: Copied or pasted text is empty.

Iteration 8: 2025-02-23 16:07:20.981 - Pasted into Notepad

Iteration 9: 2025-02-23 16:07:21.774 - Pasted into NetBeans - Error: Copied or pasted text is empty.

Iteration 9: 2025-02-23 16:07:22.812 - Pasted into Notepad

Iteration 10: 2025-02-23 16:07:23.603 - Pasted into NetBeans - Error: Copied or pasted text is empty.

Iteration 10: 2025-02-23 16:07:24.648 - Pasted into Notepad
`

I tried with and without
-J-Dorg.netbeans.NbClipboard.level=FINEST

Nothing changed...

Any idea suggestions?

[eirikbakke]

But the patch isn't well tested so far and side effects are unknown, to do something like that we should have better confidence in it. E.g the SM layer removal task #7928 was a lot of testing several mail threads. Someone would have to lead this effort.

Perhaps we should put the agent in the developer builds, now that it's early in the release cycle? That way it'll get tested for a while before we decide whether to keep it for the next release or not. (EDIT: Agent, or patch-module, or whatever we decide is better...)

[mbien]

@johntor could you also give this a try #7051 (reply in thread)? The main difference is that it replaces one JDK class instead of rewriting several at runtime. Would be good to confirm that the NB issue is solved by fixes in WClipboard and nothing outside of that class.

[johntor]

@johntor could you also give this a try #7051 (reply in thread)? The main difference is that it replaces one JDK class instead of rewriting several at runtime. Would be good to confirm that the NB issue is solved by fixes in WClipboard and nothing outside of that class.

I can not understand what do you want me to test... Please give me a procedure and I be more than happy to test and report!

[mbien]

@johntor you mentioned that you are affected by the clipboard issues and I believe I read somewhere that you said you tried the agent and it fixed it. Would be great if you could disable the agent again and try it again with the steps described in #7051 (reply in thread)

It is essentially the same procedure, a jar and a flag.

[eirikbakke]

OK, so it seems that @mbien's patch-module approach works, too, as tested by @johntor and myself here.

Having looked at the agent code I agree that this method is probably the better of the two approaches, provided that sun.awt.windows.WClipboard remains stable. Perhaps we could set up a test that fails if it changes in the OpenJDK repo?

[wumpz]

Thinking about the latest findings (@xxDark) I find it strange that the clipboard seems to be not useable using the Java Editor but nearly without any problems from the Output or IDE Log windows.
IMHO there is something wrong with some Java Editor special transfer flavors. Right?

[xxDark]

Output or IDE Log windows

Can you elaborate on what "IDE log windows" you are talking about?

IMHO there is something wrong with some Java Editor special transfer flavors. Right?

Well yes, but no. The problematic code is only executed if there are any flavor listeners attached to the clipboard. But you can never be sure in a such big application as NetBeans whether something won't register a flavor listener even if all usages of them are removed from NetBeans. So I don't think that trying to get rid of use of flavor listeners is a feasible approach (although it will probably "fix" the issue (or at least make it disappear)).

[wumpz]

If you build a project, then there all log stuff goes:

So simply a text/plain flavor, while the java editor seems to integrate a more specialized code flavor.

[VGrytsenko2022]

clipboard doesn't work (( it's impossible to work

[johntor]

Add to your

netbeans\etc\netbeans.conf

-J-DTopSecurityManager.disable=false
-J-Djava.security.manager=allow
-J-Dorg.netbeans.NbClipboard.level=FINEST

Working good for me
Windows 11
Microsoft Windows [Version 10.0.26100.3323]
Open JDK 23.0.2
Netbeans 25 (Platform Independent Binaries)

[johntor]

Option no2 clone/build xxDark's clipboard-agent
Follow the instructions...
The only problem I had was my Java version so I changed line 9 to:
java.toolchain.languageVersion.set(JavaLanguageVersion.of(23))
in build.gradle.kts

This options I think is much faster. In previous solution clipboard seemed a bit leggy (to cut a method took a few msec and it was noticeable).

[VGrytsenko2022]

Hello. Thanks for the advice. Managed to minimize the inconvenience. I haven't seen any problems for the last two days.

[istinnstudio]

xxDark's clipboard-agent fixed the issue without using FINEST. Perfect results for test code, 256 iterations. Yes, java.toolchain.languageVersion.set(JavaLanguageVersion.of(23)) needs reform upon build as
johntor mentioned earlier. I have used the simplest path possible to be able to activate the agent in conf:
-J-javaagent:C:\\clipboard-agent.jar
No mutter the complexity, as far as I can see, this is the first real solution that works flawlessly. Thanks
@xxDark

[istinnstudio]

Thanks for testing, @istinnstudio ! Did you use the test code from #3962 (comment) ? (Thanks again to @bradvido for providing that test code! I used it myself to test the @xxDark's agent a few days ago.)

Yes that is the test code with subtle changes. Without FINEST or agent, test is failing almost immediately. Keep in mind that something changed on windows behavior! ALT+TAB cannot preserve the last opened window (a windows new paranoid bug/feature?), so for now just test while no other window is open except NetBeans itself and the notepad instance that will open. If not the test code will select the wrong window.

[istinnstudio]

I confirm that the "patch" also works ok for me, -J--patch-module=java.desktop=C:\\java_desktop_clipboard_patch_17plus.jar

[mbien]

@istinnstudio thanks for checking!

[bradvido]

I tested with the java_desktop_clipboard_patch_17plus.jar patch method, and confirmed that 50 iterations of my test code #3962 (comment) were successful using JDK 17.

THANK YOU @mbien @xxDark and all who have helped!

[eirikbakke]

@bradvido Thank you yourself for providing the invaluable reproducer code!

[matthiasblaesing]

@neilcsmith-net made me aware, that there is the idea out there, that not using flavor listeners might also fix the problem. He also mentioned, that there are not that many places in the codebase that use them. Indeed outside the tests only NbClipboard and ExplorerActionsImpl use them. This was created to enable experimenting:

master...matthiasblaesing:netbeans:flavorlistener_test

When run as <NBPATH>/bin/netbeans64.exe -J-Ddisable-flavor-listener=true flavor listeners are not registered and this makes it possible to test the testcase from @bradvido with and without them.

My result was, that with 15 iterations, I could reproduce the problem without the system property and could not reproduce it anymore with flavor listeners disabled.

[neilcsmith-net]

@mbien yes, sorry, you crossed over with my edit! 😄

[mbien]

the flavor event mechanism was added so that UI can prepare itself for the active flavor (e.g. enable paste button if compatible). To my knowledge there is still no way to listen to the clipboard outside of polling.

https://bugs.openjdk.org/browse/JDK-4259272

on window activation the clipboard is polled and the events fire, that is why the current system clipboard entry is inserted on copy/paste from external applications.

[neilcsmith-net]

Yes, I knew that, once .. brain freeze today! 😆 It is specified that calls might be redundant and the result of clipboard rather than flavor changes mind you.

I'm trying to understand why this was added to NbClipboard, and whether it served any purpose. It's a limited way to track external contents, assuming the flavor listeners are called, but we ignore those calls anyway. And internal changes are primarily tracked via NbClipboard::setContents, which the editor doesn't call since NB25. That means the flavor listener really didn't add anything to the pre NB25 behaviour as far as I can tell. Currently it does give us first editor value in the history, somewhat by chance. I don't see that as a reason to keep it.

Now copy and pasting in the explorers (eg. Project, Favorites, etc.) does still call through NbClipboard::setContents. We might consider something similar to https://github.com/apache/netbeans/blob/master/platform/openide.explorer/src/org/netbeans/modules/openide/explorer/ExplorerActionsImpl.java#L618 for editors?

[mbien]

I had the same thought. Although maybe not setContents(), it would be probably sufficient to call NB's fireClipboardChange(). It should be in the system clipboard at this point already without having to set anything.

[neilcsmith-net]

If it delegated first, sure. We might want one code path used by these things though.

[eirikbakke]

@matthiasblaesing If that works it will be amazing. Thanks for trying it! What do the flavor listeners do? Can we live without them?

[xxDark]

Flavor listeners listen for clipboard changes in realtime. Yes, it does fix the problem because the problematic OpenClipboard call is made only if there are any flavor listeners registered.

[stodge]

If a fix for this has been committed, will it be introduced in an update to NetBeans 25, or will it be released in a new version, NetBeans 26?

[neilcsmith-net]

No workaround (it is a JDK bug) has yet been committed. Any changes will be in NetBeans 26.

[istinnstudio]

The fact that there is a fully functional workaround for this jdk bug is a miracle after 10 years of delirium. So a big thanks!!! to xxDark. Independently of the fix that will be implemented, in my opinion, we have to advertise this bug solution at social media, because this is not just a bug, nobody can estimate the damage that has been done to windows users over the years.

[matthiasblaesing]

So another approach. As the agent idea is not well received, I tried to reproduce the problem with a plain JTextArea and a flavor listener. The problem is not reproducible there. So it is not just the flavor listener. Based on @xxDark analysis and @mbien idea to rebuild the JDK I augemented a JDK build with logging of the WClipboard#openClipboard and WClipboard#closeClipboard calls, including the stack traces.

I indeed saw two calls running in parallel, one from the native callback listening for clipboard changes and one coming from NetBeans copying data. The latter came from org.openide.text.QuietEditorPane.DelegatingTransferHandler.exportToClipboard(JComponent, Clipboard, int). At that point the editor directly accesses the system clipboard and tries to export data. Given, that NetBeans has an abstraction called ExClipboard with the implemention NbClipboard, which goes to great lengths to retry copying, I created:

#8394

with that I get this result from the reproducer:

The reference from master showed many gaps on the notepad.exe side.

It would be great if others (@istinnstudio, @xxDark, @bradvido) could test the nightly available from: https://github.com/apache/netbeans/suites/36719959239/artifacts/2885407474

Two comments:

• there are other areas in the codebase that make calls to the clipboard, which might also need similar treatment for a complete fix, but the editor is the biggest pain point IMHO
• this might(!) fix clipboard history partly, as it routes the copy operation through NbClipboard (untested!!!!)

[johntor]

I can confirm that this is almost working...

I extracted the artifact, changed only netbeans_jdkhome.

I run on Windows 11, Open JDK 24.

I imported my plugins.

I run CopyPasteTest 10 times with maxTries = 20 while waiting before each execution.

I had 4 times perfect run...
I had 6 times I lost 1 copy to Netbeans...

Thank you matthiasblaesing !!!

I'm available for testing...

[bernardladenthin]

It works quite often for me, but the issue still persists. Pressing CTRL + X seems to restore the functionality.

Product Version: Apache NetBeans IDE DEV (Build dev-b5fca23d1e71965ce2c8e6914921a87e75800f63)
Java: 21.0.6; Java HotSpot(TM) 64-Bit Server VM 21.0.6+8-LTS-188
Runtime: Java(TM) SE Runtime Environment 21.0.6+8-LTS-188
System: Windows 11 version 10.0 running on amd64; UTF-8; de_DE (nb)

[eirikbakke]

As the agent idea is not well received

A non-agent solution would be nice, but speaking for myself, I don't think the agent solution is actually that bad, given that it addresses the underlying bug directly, and fixes it completely. I'd prefer the agent approach over partial solutions that merely make the bug more intermittent again.

[matthiasblaesing]

Nobody bothered to make this a JDK bug and I have doubts, that it actually is. The agent solution from @xxDark works because it forces the interaction with the clipboard into the EDT and thus serializes access to it as QuietEditorPane accesses the clipboard also from the EDT. I this moves the problem from "nearly always" to "hard to reproduce", it is a partial win. If there is a confirmed JDK bug, the agent is still an option.
Edit: The hard part is make this reproducible without NetBeans and without violating AWT contracts.

[eirikbakke]

Nobody bothered to make this a JDK bug and I have doubts, that it actually is.

There's definitively a JDK bug, as @xxDark managed to cause assertion failures in the JDK when the code was called from the wrong thread. If NetBeans fixes it with an agent patch, and it proves to work well over time, that may help convince OpenJDK to fix it upstream eventually.

I this moves the problem from "nearly always" to "hard to reproduce", it is a partial win.

I don't think that's good: For the purposes of actually fixing the bug, "nearly always" is something we can work with. "Hard to reproduce" is much more frustrating.

Why is there still pushback against the agent solution?

[matthiasblaesing]

Why is there still pushback against the agent solution?

On the personal level: Because some PMC members are very vocal against this. I have no intention to fight on this, maybe I'll cast a 0/-1 vote on release, to make it known, that I don't agree with their assessment, but I will not go down the "discuss ad-infinitum" route.

On the technical level: Because it is ugly. Forcing clipboard interaction into the EDT is one possible solution. We don't know yet how a full solution might look like and how this will play out. I have hoped, that this would be reproducible with plain swing, the first try failed for me and someone might file and issue against the JDK, that did not happen.

[eirikbakke]

Hmm, tricky. On one hand I think it's really important to fix this bug, on the other hand it's also really important that volunteers don't lose motivation and energy over this.

Is this a case where a simple vote might now be helpful? E.g. "Are PMCs OK with an agent-based solution to the Windows clipboard bug, despite its acknowledged ugliness?"

[neilcsmith-net]

Is there pushback against the agent solution? Saying it needs to be optional and ultimately controlled via conf, or that we should ideally look to have any agent as a temporary solution ("because it is ugly"), is not pushback against having one IMO.

[xxDark]

I will try to make a reliable reproducer. The problem is that DWM/epxlorer really does not like rapid clipboard interactions. Rapidly interacting with the clipboard causes explorer to stop responding to key presses, including ctrl-alt-delete.
Edit: it breaks the whole system, apparently. So DWM just gave up. I love Windows.

[matthiasblaesing]

At this point the changeset is merged into JDK master and thus will be part of JDK-26. The fix missed the start of RDP1 Phase of JDK-25 by a few days. I have a request sent to client-libs-dev for the option to create a backport:

https://mail.openjdk.org/pipermail/client-libs-dev/2025-June/029788.html

So at this point I time it is IMHO to early to decide how to continue.

[johntor]

I think it's too early to speak for removal! We have to wait until JDK26 became mainstream and NB drop support for versions prior to 26.
It will take a few years I think...

Many thanks to everybody worked for the JDK change! Great Job!

[neilcsmith-net]

No, we need to wait for it to be backported to all the latest updates of the versions of the JDKs we support. I hope that happens substantially earlier than us requiring JDK 29 (assuming next LTS).

Many thanks to all who worked to get the JDK fixed! Let's hope it gets backported speedily. 😄

[mbien]

the good thing about the JDK fix is that it touches files which didn't change in a while. This makes backports easy and I believe also increases the probability that it will land in all LTS JDKs NB is currently supporting - but it can take a while.

There is no rush to remove the agent quickly, but once NB can run on a JDK which includes the fix, we should make sure that there is no unexpected interaction between agent and jdk fix. @matthiasblaesing might have checked this already during tests?

[matthiasblaesing]

Backport to JDK25 is done, Backport to JDK21 is open.

[matthiasblaesing]

An updated version of the "agent approach" is available from #8361 (comment: #8361 (comment)): Checks page direct download.

I tested successfully with the reproducer code, more tests would be appreciated.

[johntor]

I can confirm that this is working!!!

I extracted the artifact, changed only netbeans_jdkhome.

I run on Windows 11, Open JDK 24.

I run CopyPasteTest 10 times with maxTries = 20 while waiting before each execution.

I had 100% perfect run!

Thank you!!!

[eirikbakke]

@matthiasblaesing Thank you! Seemed to work when I tested on my old Windows laptop with CopyPasteTest. The direct download version you posted here did not exhibit the bug, while as a control, a plain install of NetBeans 25 did once again exhibit the bug.

[LouisCollet]

seems to be fixed in NB 26-rc1 after some hours of work !!

[predi]

I'm still on NB 25 with the patch from @xxDark. While copy/paste works, I have issues with NB's "Paste from history" action. The Paste from history popup only seems to be filled with new entries occasionally but I'm unable to reproduce this reliably. For example, if I copy text from this text field on GitHub (Firefox), the new entries always seem to be properly added. However, if I attempt the same from open editor tabs within the IDE, it only adds new entries to the popup sometimes and almost never if I try within just one editor tab. I can't copy two code constructs at the same time in order to paste them into the same editor tab.

Essentially, all I'm doing is a couple of CTRL+Cs, followed by CTRL+SHIFT+D to bring the popup up.

Just tried with NB 26-rc1. Same behavior.

[neilcsmith-net]

This is a known and separate issue linked to the removal of the security manager. It is possible that #8394 would fix this.

[mbien]

this is a separate issue and not directly related to the jdk race condition. (also discussed here #7051 (reply in thread) and other places).

A quick fix would be to let the editor fill into history directly. However the feature itself is technically no clipboard history, since it doesn't display system clipboard history. It adds the most recent item on window focus change from the system clipboard - thats it.

This is likely OK, otherwise NB would have to poll the system clipboard and spy on it - which probably nobody wants for multiple reasons + polling clipboard can be very expensive. Its more of a UI naming/communication issue.

[predi]

Apologies for bringing this up again. I missed those responses when searching for "history".
FWIW, this feature did work as expected with NB 18, which is what I used before jumping to 25 (on the same system).

[matthiasblaesing]

@predi For the history part it would be great if you could test the nightly available from #8394 (Checkspage, direct download)

[ivan-velikanov]

It seems this has been fixed in netbeans 26.

As I was upgrading to netbeans 26, i and applying this clipboard java agent patch, I noticed this is already there in the configuration. Haven't tested, but glad to see this much needed patch is included.

Thanks to everyone. @xxDark much gratitude

I have been using netbeans since almost 2008, and mostly on windows.
Somehow this weird clipboard bug randomly appeared a few years ago, I would keep updating netbeans thinking it will go/vanish in the latest version.
Last month only i discovered it is a JVM bug and applied the patch and got rid of it! Finally after a decade of random and worsening issue it is solved.

Thanks to everyone again.