Re: TestBot job 94484 results: [PATCH 2/2] ole32: Do not link OLE clipboard object lifecycle to OLE initialization state.
On 7/23/21 21:18, Marvin wrote:
=== debiant2 (64 bit WoW report) ===
ole32: clipboard.c:1067: Test failed: OleIsCurrentClipboard returned 0 clipboard.c:1135: Test failed: 1 WM_DRAWCLIPBOARD received
Doesn't seem related to my patches, but I could reproduce this and other random failures locally (both with and without my patches). One sort of such failures I looked into (I suspect that relates to all of them actually) was due to the race between the test working with the clipboard and winex11.drv clipboard operation from explorer process (like, opening clipboard from X11DRV_SelectionRequest()). That selection request seems to be triggered by window creation and thus interferes with the test. I haven't debug that in details yet. Is it maybe a known issue?
On Fri, 23 Jul 2021, Paul Gofman wrote:
On 7/23/21 21:18, Marvin wrote:
=== debiant2 (64 bit WoW report) ===
ole32: clipboard.c:1067: Test failed: OleIsCurrentClipboard returned 0 clipboard.c:1135: Test failed: 1 WM_DRAWCLIPBOARD received
Doesn't seem related to my patches, but I could reproduce this and other random failures locally (both with and without my patches). One sort of such failures I looked into (I suspect that relates to all of them actually) was due to the race between the test working with the clipboard and winex11.drv clipboard operation from explorer process (like, opening clipboard from X11DRV_SelectionRequest()). That selection request seems to be triggered by window creation and thus interferes with the test. I haven't debug that in details yet. Is it maybe a known issue?
My current understanding on this is that X11DRV_SelectionRequest() should only interfere with the clipboard if the desktop environment has a nosy clipboard manager that wants to know what's in the clipboard at all times.
debiant2 is running fvwm and thus should not have any such issue.
This is based on my analysis of user32:clipboard which was failing on my KDE desktop for this reason but did not fail on the TestBot VMs. user32:clipboard now has "counter-measures" which allow it to succeed everywhere. I have been distracted with other issues so I have not yet had time to look into the other clipboard tests. I suspect they have similar issues but since this failure happens on debiant2 it may be different.
When you say you can reproduce the issue, is that in your regular desktop environment? Is it KDE?
When you say you can reproduce the issue, is that in your regular desktop environment? Is it KDE?
It was Gnome Classic.
On Sat, 24 Jul 2021, Paul Gofman wrote:
When you say you can reproduce the issue, is that in your regular desktop environment? Is it KDE?
It was Gnome Classic.
I don't know if Gnome Classic comes with a clipboard manager enabled by default (it may actually depend more on the Linux distribution). There's Glipper that can be used there, but it could also be GPaste or CopyQ.
There's also Klipper (KDE), Clipman (XFCE), Diodon, Pastie, Parcellite, Clipit, Clippy, etc. I did not know there were so many.
-
Francois Gouget -
Paul Gofman