search

apache / netbeans

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

This is just a naive attempt to fix Windows Clipboard #4572

Closed lkishalmi closed 1 year ago

lkishalmi commented 2 years ago

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 commented 2 years ago

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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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

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

neilcsmith-net commented 1 year ago

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 commented 1 year ago

@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 https://github.com/apache/netbeans/pull/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 commented 1 year ago

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:

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

eirikbakke commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

eirikbakke commented 1 year ago

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

https://github.com/apache/netbeans/pull/4774

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

swpalmer commented 1 year ago

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).