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

[Flaviu Tamas]

Hi, following up here. Turns out this bug has already been reported:
https://bugs.openjdk.org/browse/JDK-7000965

Would appreciate it if someone would sponsor this work, as described
in https://openjdk.org/contribute/, section 4.

On Mon, Jan 2, 2023 at 8:00 AM Flaviu Tamas <tamasflaviu at gmail.com> 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.