[PATCH] Paste fails when X clipboard is in a certain state

[Philip Race]

Note that fixes aren't accepted as patches.
You need to submit a github PR after signing the OCA and getting it 
recorded.
https://openjdk.org/contribute/

However I've re-opened this bug (I do not understand why it was closed) and
assigned to someone might be able to find time to take care of it.

-phil.

On 10/18/22 9:08 PM, Flaviu Tamas wrote:
> Sometimes, the X clipboard is in some state that causes pastes to fail
> with the following, or similar, stack traces:
>
> java.lang.NullPointerException: Failed to retrieve atom name.
>      at java.desktop/sun.awt.X11.XlibWrapper.XGetAtomName(Native Method)
>      at java.desktop/sun.awt.X11.XAtom.getName(XAtom.java:189)
>      at java.desktop/sun.awt.X11.XDataTransferer.getTargetNameForAtom(XDataTransferer.java:172)
>      at java.desktop/sun.awt.X11.XDataTransferer.getNativeForFormat(XDataTransferer.java:161)
>      at java.desktop/sun.awt.datatransfer.DataTransferer.getFlavorsForFormatsAsSet(DataTransferer.java:487)
>      at java.desktop/sun.awt.datatransfer.SunClipboard.formatArrayAsDataFlavorSet(SunClipboard.java:342)
>      at java.desktop/sun.awt.datatransfer.SunClipboard.isDataFlavorAvailable(SunClipboard.java:185)
>
> This is a widespread issue and very frustrating issue, see:
>
> - https://youtrack.jetbrains.com/issue/JBR-438/Clipboard-operations-arent-working-in-certain-state-of-Xorg-selection-buffers
> - https://www.google.com/search?q="Failed+to+retrieve+atom+name"+"DataTransferer"
>
> Frankly, I don't understand how X works at all, or how this issue
> arises. However, this same workaround was applied to Mozilla in 2010:
> https://hg.mozilla.org/releases/mozilla-1.9.1/rev/62f3d28797e2, and I
> don't see any reasonable behavior that having this workaround in place
> would break. The workaround works by simply skipping native formats
> that don't have a name.
>
> Verified to work by running IntelliJ Clion under the modified VM and
> verifying that paste from my terminal, which previously did not work,
> now works. I'm not familiar with OpenJDK unit testing conventions, but
> I believe this change falls under the "highly platform-dependent"
> exception.