search

apache / netbeans

Apache NetBeans
https://netbeans.apache.org/
Apache License 2.0
2.64k stars 846 forks source link

Problems with copy and paste in windows #3962

Open andersonneto opened 2 years ago

andersonneto commented 2 years ago

Apache NetBeans version

Apache NetBeans 13

What happened

This issue has been occurring in this version and earlier. Sometimes when we copy text from a website/browser on Windows operating system, Netbeans pastes information that was copied into Netbeans itself. And many times, I select from the website and drag it to Netbeans, to paste the text.

How to reproduce

The problem is only solved when I restart the application. Note: After presenting the problem, when a blank text is copied inside Netbeans, sometimes, when we copy a text externally, it manages to paste inside Netbeans. If pasted in any Windows environment, the text goes correctly, but within Netbeans, it copies the last information copied into the application.

Did this work correctly in an earlier version?

No

Operating System

Windows

JDK

16.0.2 (64bit)

Apache NetBeans packaging

Apache NetBeans binary zip

Anything else

No response

Are you willing to submit a pull request?

Yes

Code of Conduct

Yes

neilcsmith-net commented 2 years ago

Unfortunately a long standing annoyance, which doesn't seem to have a definitive reproducible cause, or we know whether it's definitely NetBeans or the JDK at fault. Have a read of https://lists.apache.org/thread/xqkwy4wxylmzprxl1wko301hlqz59r7d and some of the flags, logging settings, etc. Be great to get to the bottom of this one!

Montanajim commented 2 years ago

This is very annoying problem. I teach coding. Usually I code in a Google doc because it is live and students can follow along easily. When I want to compile my code I paste it into NetBeans. It fails and only pastes the last thing I copied from within Netbeans. Apparently the copy and paste works only within Netbeans. THIS IS A PROBLEM. Please fix!

The work around is to open the source file concurrently in a text editor and copy and paste there which updates the source file in Netbeans.

neilcsmith-net commented 2 years ago

@Montanajim if you have a reliable reproducer, then please share as much information as you can about environment, JDK, Windows version, browser you're pasting from, etc. Does it reproduce immediately, or after a time? Is it after a particular type of content has been added to the clipboard (from anywhere)? Do any of the suggestions in the linked thread above help? Is it NetBeans specific, or can you reproduce with other Java (Swing) applications?

It's well known that this is a problem, just not what the fix should actually be!

KKuehlem commented 2 years ago

I can reproduce the bug through these steps:

  1. Copy a piece of text in Netbeans
  2. Paste the text in an applicaiton
  3. In From this application copy some other text
  4. Paste the text into netbeans
  5. Paste it somewhere
  6. Copy text again
  7. Every new copy from netbeans from now on will not work anymore. If I do not copy in an outside application the clipboard will now be empty (and not the text from step 6 anymore)

I tested these steps with Notpad++, Firefox and the windows file explorer and have the same result exactly after these steps. Also if I mix applications in between. I checked the logs but no error was reported. I am running Netbeans 13 on Windows 10.0 on amd64 with Oracle JDK 17 (17+35-LTS-2724) but had the same issue on older JDKs.

If I can send you any log files or if I can help somehow please write me.

NicolaIsotta commented 2 years ago

This happens also in Windows 11 with AdoptOpenJDK 11 and Netbean zip distribution

duoduobingbing commented 2 years ago

I have the same Problem. It occurs with any Apache Netbeans version (ranging from NB9 to NB15) and with every JDK Build on Windows that I have tested. This includes Java 8, 11 and 17 via Eclipse Temurin JDK, Azul Zulu JDK and some other JDK builds.

The bug occurs seemingly random.

Edit: Please see @epliskin's workaround as it also works consistently and does not require the extra plug-in from NB 7.1

I have found a workaround that works consistently:

Setup

Workaround

When the bug occurs, then press Alt+V in NB editor to open the clipboard history and insert any item from the menu that should have been opened by the plugin. Press Ctrl+Z to revert the insertion. The clipboard should work normally now.

Performing the Workaround before the bug occurs does not stop the bug from happening. Only performing the workaround after the bug occurs fixes the problem until the bug occurs again.

pryshrm commented 2 years ago

Same issue with NB 13 and JDK 17. Doing a Control + c in netbeans and then control + v in netbeans works but control + v in another application doesn't work. In the other application stuff that was copied earlier is pasted (not the stuff that was copied most recently from NB). Reverse doesn't work either.

Doing empty Control+C (i.e. cntrl c without selecting any text) seems to reset this behavior. So, if ctrl v is not pasting the right stuff, do an empty ctrl c in netbeans and then select stuff and cntrl c to copy it. Now do ctrl v on another application to paste. It works.

Once it is pasted, then the problem resurfaces. So you have to do an empty cntrl c again to reset. Crazy.

wumpz commented 2 years ago

Same issue with NB12 and NB13 platform applications using JDK 11, 16, 17.

micky008 commented 2 years ago

I have the same problem. Windows OpenJdk 16.0.2.

the workaround by @duoduobingbing did not work the Copy and Paste History. The link is dead.

anyone have a workaround too ?

lkishalmi commented 2 years ago

A naive attempt to fix: #4572

Also you may add the following command line option to netbeans.exe (or put it into netbeans.conf):

-J-Dnetbeans.slow.system.clipboard.hack=false

That'd switch off NetBeans Clipboard handling hacks which is enabled by default on all platforms save Mac.

Those hacks were introduced as a workaround for an AWT System clipboard issue around Java 5. They might be obsolete and causing issues now.

Please report back your experience either you are trying a build with the PR or testing the app with the provided flag!

NicolaIsotta commented 2 years ago

Testing the command line option with Netbeans 14 on Windows 11 and Java 11 The issue persists

neilcsmith-net commented 2 years ago

Thanks @NicolaIsotta Could you also try with -J-DTopSecurityManager.disable=true.

When you say it persists, is it immediate, or does it happen after some time? If after a time, is there anything you're doing that seems to be a common trigger? Is there anything that seems relevant in View / IDE Log around the time the problem starts occurring?

errael commented 2 years ago

Are you able to get a log of when it goes south. There discussion of this in

https://lists.apache.org/thread/nsg2pdzrs3go9f4zlhy0gjs2hfxmbdbn

But basically

Edit the netbeans.conf file in netbeans/etc/ to add:
 -J-Dorg.netbeans.NbClipboard.level=FINEST
lkishalmi commented 2 years ago

Also check with Java 17. This issue is on how Native Clipboard communicate with the JVM, so the JVM can count as well.

epliskin commented 2 years ago

Same issue with NetBeans 15, JDK 17, Windows. Based on duoduobingbing advice above the workaround is simply to open the built-in NetBeans clipboard history dialog with (Ctrl+Shift+D), select an item from history to paste into NetBeans editor and revert insertion with (Ctrl+Z). This magic revitalizes the NetBeans clipboard.

lkishalmi commented 2 years ago

It is so strange that we do not get feedback from the Windows folk running the IDE with -J-DTopSecurityManager.disable=true or -J-Dnetbeans.slow.system.clipboard.hack=false...

KKuehlem commented 2 years ago

-J-DTopSecurityManager.disable=true does not work for me at all, when I am using this option I cannot use the clipoard anywhere outside netbeans. -J-Dnetbeans.slow.system.clipboard.hack=false does work for me, if not combined with -J-DTopSecurityManager.disable=true. Still, I have to recopy text in netbeans to paste it somewhere else.

Besides, using the clipboard history, as mentioned by @epliskin , also works for me. (I am using Netbeans 14 on Oracle JDK 17)

epliskin commented 2 years ago

An hour ago I configured netbeans.conf with (-J-DTopSecurityManager.disable=true -J-Dorg.netbeans.NbClipboard.level=FINEST) and started NetBeans 15 with JDK 17. Clipboard works as yet fine between NetBeans and other Windows programs. At this time I do not edit any code eagerly but will report here in coming days or weeks if and when NetBeans clipboard freezes again...

duoduobingbing commented 2 years ago

I wanted to thoroughly test before writing that this and that option definetely works or does not work; but here are my results after running with some options for a longer time:

epliskin commented 2 years ago

See attached NetBeans log for this bug. I was editing some code when it happened. Could not paste from other Windows app, could not copy from NetBeans to another Windows app, but still could copy and paste text inside NetBeans editor.

netbeans_default_options = ... -J-DTopSecurityManager.disable=true -J-Dorg.netbeans.NbClipboard.level=FINEST

messages.zip

epliskin commented 2 years ago

And again some time after NetBeans restart...

messages2.zip

F-I-D-O commented 1 year ago

I have the same problem with Netbeans 16, JDK 18. I have experienced the problem only in Java files so far, when I copy a text from pom.xml, for example, it works fine. Adding -J-Dorg.netbeans.NbClipboard.level=FINEST to netbeans.conf seems to fix the problem.

micky008 commented 1 year ago

I have the same problem with Netbeans 16, JDK 18. I have experienced the problem only in Java files so far, when I copy a text from pom.xml, for example, it works fine. Adding -J-Dorg.netbeans.NbClipboard.level=FINEST to netbeans.conf seems to fix the problem.

Yes. i confirm. it works.

neilcsmith-net commented 1 year ago

Adding -J-Dorg.netbeans.NbClipboard.level=FINEST isn't a fix, and judging from @epliskin comments doesn't always mask the issue either. Enabling all the additional logging might be helping with a race condition, or maybe eagerly acquiring the transfer data in logFlavors() is helping - https://github.com/apache/netbeans/blob/master/platform/o.n.bootstrap/src/org/netbeans/NbClipboard.java#L288

spyhunter99 commented 1 year ago

ha i've seen this problem since i started using netbeans v5. Still happens today. Seems more frequent of an issue with nb17 that in previous versions

wumpz commented 1 year ago

Same issue with NB14, NB15, NB16, NB17 platform applications using JDK 11, 16, 17. This is very annoying. The most disturbing part is that all of our Netbeans Platform applications are affected.

Please address this issue. Most of the "hacks" do sometimes work but not always.

neilcsmith-net commented 1 year ago

Please address this issue. Most of the "hacks" do sometimes work but not always.

Then please help figure out what the cause of the issue is. If this issue was consistently reproducible or we knew what was causing it, it'd be fixed already!

wumpz commented 1 year ago

-J-Dnetbeans.slow.system.clipboard.hack=false seems to work for me. NB 17 and JDK 17.

cquoss commented 1 year ago

Where can this issue be upvoted? Because it is very annoying. A core functionality not working properly.

neilcsmith-net commented 1 year ago

@cquoss just try some of the suggestions above and report back if anything helps! Upvoting is pointless - we know it's an issue - we need to be able to replicate the problem, or know what is a reliable workaround, in order to be able to fix it.

istinnstudio commented 1 year ago

a stupid partial "clearance" of the bug (until it is re introduced) is to copy any class from the project tab (mouse right click copy), then copy paste will work again from external sources. If an "internal" editor copy will occur again the bug can be re-introduced.

istinnstudio commented 1 year ago

J-Dorg.netbeans.NbClipboard.level=FINEST does not work here. If this bug will be laying around forever wouldn't it be better to just make some kind of macro workaround until the final track/fix, in order to unlock the right behavior?

I do not know how valuable my note might be. I will try.. @developers, maybe a temporal solution would be something like: When trying to paste something in editor, copy the "non able to paste" data (from windows clipboard) to an other temporary place in ram (using a different a way to copy clipboard than editor will erroneously do), then copy a dummy data entry in projects/editor "internally" (a dummy class object maybe) and then recopy (yes again) the previously temporarily saved data on top of it, I guess then paste will be unlocked and possible at least as a workaround. I confirm this works manually, but only after recopying (2nd time) manually the original content to be copied after the bug appearance, many steps/clicks for nothing but at least this seems to work. Please change this bug as critical in order to gain the right attention. We cannot continue like this for ever.

newk5 commented 1 year ago

-J-Dnetbeans.slow.system.clipboard.hack=false -J-Dorg.netbeans.NbClipboard.level=FINEST fixed it for me

Windows 11, Netbeans 16, JDK17

istinnstudio commented 1 year ago

-J-Dnetbeans.slow.system.clipboard.hack=false -J-Dorg.netbeans.NbClipboard.level=FINEST fixed it for me

Windows 11, Netbeans 16, JDK17

I will check this. I have missed the first statement -J-Dnetbeans.slow.system.clipboard.hack=false... hopefully both will do the trick

edit: this does not work for me either, I am linking again to the original patch that goes deeper in those "hacks": https://github.com/apache/netbeans/pull/4572

NewLifeDreamer commented 1 year ago

The same problem. I am considering to use an alternative IDE. NetBeans 18, JDK 19, Windows 11 Home

wumpz commented 1 year ago

I started to dig into this and in my environment the external Clipboard data was received in Netbeans in NbClipboard. The problem seems to occur while transferring to ClipboardHistory. I had the actual (correct) data in the history list tooltip but inserted got the last Netbeans copied data.

Could that be a way to go further?

BTW: Netbeans 18, JDK 17, Windows 11

istinnstudio commented 1 year ago

Please give attention to notes like this one, I think this bug has to change priority as it is so frequent that is killing everyday usage experience.

wumpz commented 1 year ago

Switching off Netbeans special clipboard handling seems to improve situation as well:

TopSecurityManager.makeSwingUseSpecialClipboard(Lookup.getDefault().lookup(ExClipboard.class));

used here: https://github.com/apache/netbeans/blob/d848cb34e343307bf20d8c8a0948e6f004dfa86d/platform/o.n.core/src/org/netbeans/core/NbLifecycleManager.java#L71

defined here: https://github.com/apache/netbeans/blob/d848cb34e343307bf20d8c8a0948e6f004dfa86d/platform/o.n.bootstrap/src/org/netbeans/TopSecurityManager.java#L664

To avoid this special handling you could try to switch off TopSecurityManager but I have no idea what side effects this has. So start your platform app or netbeans with -J-DTopSecurityManager.disable=true. This avoids installing Netbeans complete clipboard handling. Look into NbLifecycleManger:

public static void advancePolicy() {
        if (policyAdvanced) {
            return;
        }
        // -----------------------------------------------------------------------------------------------------
        // 8. Advance Policy
        if (!Boolean.getBoolean("TopSecurityManager.disable")) {
            // set security manager
            TopSecurityManager.install();
            if (CLIOptions.isGui()) {
                TopSecurityManager.makeSwingUseSpecialClipboard(Lookup.getDefault().lookup(ExClipboard.class));
            }
        }
        policyAdvanced = true;
    }

Strangely clipboard history still works. I had no troubles copy paste from and to external applications so far.

So this referenced bug: http://developer.java.sun.com/developer/bugParade/bugs/4818143.html still relevant?

epliskin commented 1 year ago

For me, adding -J-DTopSecurityManager.disable=true to netbeans.conf does not help.

wumpz commented 1 year ago

For me, adding -J-DTopSecurityManager.disable=true to netbeans.conf does not help.

Strange. That would mean you either put this on the wrong place or NbClipboard is not the cause of the problem. So Javas system clipboard handling would be the problem. To be honest I tested it with a platform application. Maybe within Netbeans IDE itself there is more. And I used the command line and not netbeans.conf. Where did you put it there?

neilcsmith-net commented 1 year ago

@istinnstudio have added the high priority label, although it doesn't change a lot until we have a consistent way to reproduce. It is considered high priority anyway, but it's not going to get a milestone until someone who can fix it can also reproduce it.

@wumpz IIRC that is not the only thing required to disable it being used in some key places.

epliskin commented 1 year ago

Where did you put it there?

Appended -J-DTopSecurityManager.disable=true to "netbeans_default_options" key in netbeans.conf.

At the same time I excluded two keys -J-Dnetbeans.slow.system.clipboard.hack=false -J-Dorg.netbeans.NbClipboard.level=FINEST and experience perceptible frequency increase of clipboard errors without those two keys and in presence of the -J-DTopSecurityManager.disable=true key.

wumpz commented 1 year ago

@istinnstudio have added the high priority label, although it doesn't change a lot until we have a consistent way to reproduce. It is considered high priority anyway, but it's not going to get a milestone until someone who can fix it can also reproduce it.

@wumpz IIRC that is not the only thing required to disable it being used in some key places.

You are right. This is only my small personal effort to get closer to the root of this clipboard hell. However, switching off this security manager simply switches for normal Swing components to standard clipboard behaviour. So isn't that a sign that the problem is indeed in NbClipboard?

@epliskin So sorry, that it doesn't help. I simply try to give this issue some more input, while not being a collaborator for this project myself.

istinnstudio commented 1 year ago

For me the only way to reset the clipboard madness is to copy a class from the projects tab. Then copy from e.g. a browser and paste to editor will work again, until a new series of internal editor copy/paste sessions will occur (or something else). Then the issue reappears and a new reset is needed. I cannot say this behavior can be replicated, but someone facing the issue could test and confirm this, it might be a starting point alongside with wumpz notes.

istinnstudio commented 1 year ago

I would also like to note that the issue occurs on both directions, a copy from editor and a paste to external app does not work sometimes either, the same reset described above fixes the issue for a while. So the issue can happen on both directions copy from editor to external app and from external app to editor.

bradvido commented 1 year ago

i found that if you copy an empty line in the source editor, it wil work to "reset" the clipboard and allow you to copy/paste from external programs.

Still haven't found a reliable fix using any of the previously mentioned configuration combinations.

Windows 11 / JDK 17 / Netbeans 17

wumpz commented 1 year ago

Using JDK 17 and digging deep into my logs I found:

java.lang.IllegalAccessException: class org.netbeans.TopSecurityManager cannot access class sun.awt.AppContext (in module java.desktop) because module java.desktop does not export sun.awt to unnamed module @2e817b38
    at java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:392)
    at java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:674)
    at java.base/java.lang.reflect.Method.invoke(Method.java:560)
    at org.netbeans.TopSecurityManager.makeSwingUseSpecialClipboard(TopSecurityManager.java:714)
    at org.netbeans.core.NbLifecycleManager.advancePolicy(NbLifecycleManager.java:71)
    at org.netbeans.core.network.proxy.ProxyAutoConfig$1.run(ProxyAutoConfig.java:81)
    at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1419)
    at org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:45)
    at org.openide.util.lookup.Lookups.executeWith(Lookups.java:287)
    at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2034)

guess where it is thrown: TopSecurityManager.makeSwingUseSpecialClipboard

So this method goes only half through the stuff it should do, at least in my platform application.

I needed to include: -J--add-opens=java.desktop/sun.awt=ALL-UNNAMED to get this NbClipboard stuff installed properly.

So this improves the situation in my platform application. In Netbeans IDE itself this is already set, so the problem stays.

istinnstudio commented 1 year ago 
-J-DTopSecurityManager.disable=true
-J--add-opens=java.desktop/sun.awt=ALL-UNNAMED

this does not solve the issue (in netbeans config), After a 4-5 copy paste sessions back and forth, clipboard stops responding and keeps only the last copied txt part from editor. I have noted that copying a class in project "resets" the state but as bradvido noted, copying "nothing" in editor (yes it is possible!) resets the state also, just select a line that has nothing (not even a space) and press right mouse button, then copy this "void" and the clipboard state resets. It actually copies nothing and keeps already copied material as it is... but it resets. Weird..

This looks like that a second state in clipboard exists at the same time, by copying this "void" you can use and paste the real external copied material (it is already there !!! not need to copy it again), if not, last editor copy will be used !!!

Something is messing up those double clipboard states, maybe the "void" copy is the ghost that will lead to debugging even without total replication, but the bug is so common that 4-5 back and forth copy/paste sessions will reveal it.

wumpz commented 1 year ago

@istinnstudio This is really weird. Hopefully, our investigations and informations are helping the developers to attack this nasty bug. Maybe this TopSecurityManager stuff helps only for normal Swing components. However, NbClipboard is necessary to provide all needed flavours of copying.

bradvido commented 1 year ago

My suspicion is that the problem starts to occur intermittently only AFTER the clipboard history fills up. It looks like the default size for clipboard history is 6. Is it possible to change that value to something much larger, so I can test this suspicion?