Another attempt to fix intermittent clipboard bug on Windows

[eirikbakke]

Attempt to fix an intermittent clipboard bug on Windows, where cut/paste with external applications would stop working until IDE was restarted. With this fix, the problem still occurs occasionally, but appears to go away the next time the user tries to cut/paste with an external application, without the need to restart the IDE.

This is a follow-up on #4572, with a slightly alternative approach. Instead of removing the removeFlavorListener/addFlavorListener workaround for a previous bug, we instead call fireChange() after the addFlavorChange, in case we missed some updates. This should probably have been done in any case. The effect of either version of the patch seems the same, but the version in this PR avoids sacrificing the workaround for an unrelated old bug (which may or may not still exist).

The patch probably still needs to be tested for a while to confirm that the original bug is really gone, but calling fireChange() after addFlavorChange() seems to be the right thing to do in any case, and it's good to get multiple people to test this on different machines now.

[mbien]

this probably needs the platform label. But I don't think it matters here since there are no platform tests on windows runners anyway.

more details:
https://lists.apache.org/thread/3gyc3xvxjjh8osh5rd6k81lshtno0j0z

the description mentions what tests are added for each label
https://github.com/apache/netbeans/labels?q=%5Bci%5D

[eirikbakke]

@mbien Ah, tag-conditional tests; great! Thanks for tagging.

[eirikbakke]

Now hit the bug again with this version of the patch in place. Same behavior as before: the error occurs but "fixes itself" after trying again.

In this case I was unable to copy from outside NetBeans (first from Excel, then from Notepad) and into the NetBeans Java editor. Repeated attempts at copying from the outside application did not resolve the problem, but as soon as I tried to copy something out of NetBeans, the clipboard started working again in both directions.

[lkishalmi]

@eirikbakke It would be interesting to combine this one and #4572 just removing the register/unregister pairs, but do the additional fire event on WINDOW_ACTIVATED

[eirikbakke]

@lkishalmi What is the suspected connection between the bug and addFlavorListener/removeFlavorListener code in the first place? How did you come to suspect this piece of code?

[lkishalmi]

Well, it was just: I've came across the NbClipboard searching for clipboard. Then checked, if there is some specific code for Windows as there is no such issue on Mac and Linux. Then if( Utilities.isWindows() ) got me.

Again, I could be entirely wrong here, as all I did was just suspect. I live in a Windows free environment since ~2004.

[lkishalmi]

Also, again a suspect, what if the event type we are listening on is wrong. Shouldn't we use WINDOW_LOST_FOCUS and WINDOW_GAINED_FOCUS instead. That could explain: #4572 (comment). So when NetBeans opens a new Window, that gets activated, and bang, we regain the sync with the system clipboard.

[eirikbakke]

@lkishalmi The About window could also work because it's a much simpler text pane rather than the full NetBeans editor thing.

Finding a better approach requires more of a "deep dive" into this than I can do at the moment, but I can keep testing the low-risk patch here for a while, perhaps turning it off/on again for a few days at a time to verify that the behavior really correlates with it.

Remind me, what is the timeline for NB16?

[lkishalmi]

Seems to be harmless enough, even if this does not solve the issue entirely, it's claimed to be helping.