Stabilize copy'n'paste one windows by using ExClipboard instead of directly accessing system clipboard

[matthiasblaesing]

No description provided.

[mbien]

this is certainly the most compact fix so far :-)

[eirikbakke]

For the benefit of reviewers who want to know what this is about, see #7051 (comment)

[eirikbakke]

From the comment at #7051 (comment) , it seems two people are still able to reproduce the bug with this patch.

Do we prefer partial solutions over the agent solution?

[neilcsmith-net]

I'm not sure this is a fix for the original bug. As far as I can tell, this is returning the editor specifically to the pre-NB25 behaviour. That might still be an improvement for the current situation.

[matthiasblaesing]

I still think this should also be done (for other reasons, but will not look further into this before NB26). Will reschedule.

[neilcsmith-net]

@matthiasblaesing I agree. And if one effect of this is fixing history, then I think we should still consider targeting NB26.

[matthiasblaesing]

Pushed an update with more sources covered. I grepped for usages of java.awt.datatransfer.Clipboard and getSystemClipboard. Several places are already covered by checking the default lookup for an instance of Clipboard or ExClipboard, this update enhances that approach.

[predi]

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

ref

@matthiasblaesing I did a quick test with the build from the above direct download link. Created a test Java (Ant) Application project, ensured I had two .java files open in two editor tabs.

It works as expected when copying and bringing up the Paste from history popup within a single editor tab. It also works as expected when switching between two editor tabs. When I say "as expected" I mean it behaves as it did in NB 18.

However, there is a difference in behavior when copying text outside of the IDE. If I do multiple CTRL+C commands outside the IDE (from Notepad++ in my test) only the last one will be added to the popup's list. Previously, all of these copy commands would be placed within the popup.

Also the popup is not hidden when IDE loses focus. If I ALT+TAB to Firefox that is "under" the IDE when the action occurs, the popup is drawn over Firefox. Probably an unrelated issue, but I'll just drop it here, just in case.

Still, this works much better than what I have now with NB 25 - the copying within the IDE is what I mostly do when using this functionality.

[mbien]

If I do multiple CTRL+C commands outside the IDE (from Notepad++ in my test) only the last one will be added to the popup's list.

NB does not read or poll the system clipboard history. On window re-activation, the current item on the clipboard is added to the list (which should be better deferred until its pasted IMO). This shouldn't be changed since no IDE should spy on the system clipboard and store entries in memory (or even as Strings).

This is more of a communication issue, we should call it "internal clipboard history" or something like that.

[matthiasblaesing]

@predi history tracking when netbeans is not the active application was disabled as some small company in Redmond does not handle it gracefully: https://bz.apache.org/netbeans/show_bug.cgi?id=227236

[matthiasblaesing]

I plan to merge this early in the NB27 cycle, unless anybody objects.

[neilcsmith-net]

I still think it might be good to target the first commit to 26-rc3, assuming it fixes the clipboard history in the editor, then merge the rest for NB27.

[matthiasblaesing]

I still think it might be good to target the first commit to 26-rc3, assuming it fixes the clipboard history in the editor, then merge the rest for NB27.

Created as #8462. If that is merged, will rebase this PR onto that.

[neilcsmith-net]

Given comments about test failures on #8462 caused by the asynchronous nature of NbClipboard, trying a run with all tests on this.

[neilcsmith-net]

I think before this can be merged we need to decide how to address the asynchronous design of NbClipboard, and that unless paste is always called through it, there's no wait on pending changes. There are at least two options - ensure all paste uses the ExClipboard implementation, or strip out the async code from NbClipboard and just make it observable?

[matthiasblaesing]

Not sure whether I will revisit this.

[neilcsmith-net]

It is of course up to you what you want to work on, but I'll try and find some time to look at this more once NB26 is out. I think you're mostly in the right direction with this.

I just did some testing with macros in 26-rc2 and delivery, and can reproduce the timing issue that the test failure highlighted.