Cursor incorrectly modified in GTK2 apps with Xwayland

The problem happens in Fedora 38, running Wayland (xorg-x11-server-Xwayland-22.1.9-2.fc38.x86_64). When using GTK2 applications, the cursor appears to be sometimes incorrectly modified.

See this example from gtk-demo which try to illustrate the problem: Screencast_from_2023-06-07_18-42-18

When exiting from the dropdown menu area the cursor is reverted to what is was when entering in the application area (e-resize, w-resize, ...).

The bug is not systematic, and seems to depend on the order of these two calls to ChangeToCursor() (which is not always the same), when moving from the border of the window, to the interior of the application:

Breakpoint 2, ChangeToCursor (pDev=0x1a07dd0, cursor=0x1d45a10) at ../dix/events.c:936
936         SpritePtr pSprite = pDev->spriteInfo->sprite;

#0  ChangeToCursor (pDev=0x1a07dd0, cursor=0x1d45a10) at ../dix/events.c:936
#1  0x00000000004bdbc8 in PostNewCursor (pDev=0x1a07dd0) at ../dix/events.c:1003
#2  0x00000000004c2ac0 in CheckMotion (ev=0x7ffcd8200d30, pDev=0x1a07dd0) at ../dix/events.c:3226
#3  0x000000000057db33 in ProcessDeviceEvent (ev=0x7ffcd8200d30, device=0x1a07dd0) at ../Xi/exevents.c:1852
#4  0x000000000057e13d in ProcessOtherEvent (ev=0x7ffcd8200d30, device=0x1a07dd0) at ../Xi/exevents.c:2017
#5  0x00000000005c595a in ProcessPointerEvent (ev=0x7ffcd8200d30, mouse=0x1a07dd0) at ../xkb/xkbAccessX.c:756
#6  0x0000000000480d5a in mieqProcessDeviceEvent (dev=0x1be05b0, event=0x7ffcd8201970, screen=0x18c8480) at ../mi/mieq.c:508
#7  0x0000000000480f6f in mieqProcessInputEvents () at ../mi/mieq.c:563
#8  0x0000000000419a9c in ProcessInputEvents () at ../hw/xwayland/xwayland-input.c:3057
#9  0x00000000004a8f2a in Dispatch () at ../dix/dispatch.c:483
#10 0x00000000004b7438 in dix_main (argc=16, argv=0x7ffcd8202798, envp=0x7ffcd8202820) at ../dix/main.c:272
#11 0x0000000000432115 in main (argc=16, argv=0x7ffcd8202798, envp=0x7ffcd8202820) at ../dix/stubmain.c:34

and

Breakpoint 2, ChangeToCursor (pDev=0x1a07dd0, cursor=0x1d2ad80) at ../dix/events.c:936
936         SpritePtr pSprite = pDev->spriteInfo->sprite;

#0  ChangeToCursor (pDev=0x1a07dd0, cursor=0x1d2ad80) at ../dix/events.c:936
#1  0x00000000004bdbc8 in PostNewCursor (pDev=0x1a07dd0) at ../dix/events.c:1003
#2  0x00000000004c3624 in WindowHasNewCursor (pWin=0x1d45db0) at ../dix/events.c:3505
#3  0x00000000004f9753 in ChangeWindowDeviceCursor (pWin=0x1d45db0, pDev=0x1a07dd0, pCursor=0x0) at ../dix/window.c:3526
#4  0x000000000058e0d4 in ProcXIChangeCursor (client=0x1c4e520) at ../Xi/xichangecursor.c:105
#5  0x0000000000581ae4 in ProcIDispatch (client=0x1c4e520) at ../Xi/extinit.c:390
#6  0x00000000004a9113 in Dispatch () at ../dix/dispatch.c:546
#7  0x00000000004b7438 in dix_main (argc=16, argv=0x7ffcd8202798, envp=0x7ffcd8202820) at ../dix/main.c:272
#8  0x0000000000432115 in main (argc=16, argv=0x7ffcd8202798, envp=0x7ffcd8202820) at ../dix/stubmain.c:34

In this order, the bug happens.