JDK-8071668 : [macosx] Clipboard does not work with 3rd parties Clipboard Managers
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 8,8u11,8u25,9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-01-27
  • Updated: 2015-09-29
  • Resolved: 2015-03-30
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 JDK 9 Other
8u51Fixed 9 b61Fixed openjdk7uFixed
Related Reports
Duplicate :  
JDK-8057670 - [macosx] clipboard misses changes made by external clipboard manager
Duplicate :  
JDK-8061315 - [JFXPanel, Mac] need an ability to check if Clipboard has been changed from outside of Swing/AWT
Description
Java Clipboard does not work with many clipboard managers (e.g. ClipMenu, ClipboardHistory, Collective) when text is copied/pasted in
JEditorPane/JTextArea of the same application.

A focus change on a different application, will restore the correct behaviour of paste function from clipboard manager menu
Comments
According to JDK-8076250 we have the backport of the fix since 8u60 b10. UR SQE haven't seen any new issues related to the fix. Therefore, no objections to take the fix into the CPU15_03
22-04-2015
Critical Request - Justification : this problem has strong impact on user experience when working with clipboard via 3rd party clipboard managers, remote session or any other cases when the clipboard is changed by other process without switching between applications - Risk Analysis : medium. A new synchronous call added from AWT to Toolkit thread which increases the risk of deadlock according to info from AWT team (however they still couldn't reproduce this problem locally). There also JFX impact. - Webrev : http://cr.openjdk.java.net/~anashaty/8071668/9/webrev.01/ - Testing (done/to-be-done) : MacOS clipboard related tests. The regression tests didn't detect problems. - Back ports : 8u60 - FX Impact : the removed method CClipboard.checkPasteboard() is called via reflection from JFXPanel (see JDK-8061315) however this shouldn't lead to regressions, since the methodRef is checked for null and the FX problem addressed in the JDK-8061315 should be resolved by this fix (verified by Anton Tarasov) - Fix For Release : JDK 8 CPU
31-03-2015
Webrev: http://cr.openjdk.java.net/%7Eanashaty/8071668/9/webrev.00/
26-03-2015
Note: introducing a timer which polls native pasteboard will not help in case with Clipboard managers, since the clipboard change should be captured immediately
26-03-2015
Until a Java component doesn't own the Clipboard the native clipboard content is always checked. From the moment when Java takes Clipboard ownership (e.g. copy text from the JTextArea) it uses cached value until receives LostOwnership notification. The problem in that the MacOS doesn't have a way to listen for clipboard changes, client should always call the NSPasteboard.changeCount to track the changes. This was partially workarounded via checking the pasteboard on NSApplicationDidBecomeActiveNotification event. This is fine for the major usecases, however doesn't work when someone changes the content 'in background'. The solution might be to check for the native pasteboard changes on each Clipboard.getContent() call instead of relying on LostOwnership notifications.
26-02-2015