[Bug 59257] New: RTF clipboard reads randomly chosen string (regression from wine 10)
http://bugs.winehq.org/show_bug.cgi?id=59257 Bug ID: 59257 Summary: RTF clipboard reads randomly chosen string (regression from wine 10) Product: Wine Version: 11.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winex11.drv Assignee: wine-bugs@list.winehq.org Reporter: ssb22@cam.ac.uk Distribution: --- After placing text on the X11 clipboard from Emacs 29.3 in Ubuntu 24.04 LTS and attempting to paste this into a Windows program that is set to read RTF clipboard when available, the Windows program alternately comes out with "emacs" or my full name or some other string, none of which are what I put on the clipboard. The code below minimally demonstrates the issue. Use `i686-w64-mingw32-gcc test.c` and `wine a.exe` after placing some text onto the clipboard from Emacs. This works correctly in WINE 10 but fails in WINE 11, potentially feeding randomly-chosen private strings to the Windows program instead (I was unable to figure out how it got my full name when this was not on the clipboard, but it's clearly somehow reading from some part of memory it shouldn't). ```c #include <windows.h> #include <stdio.h> int main() { UINT cfRtf = RegisterClipboardFormat(TEXT("Rich Text Format")); if (!OpenClipboard(NULL)) { printf("Failed to open clipboard\n"); return 1; } if (IsClipboardFormatAvailable(cfRtf)) { HANDLE hData = GetClipboardData(cfRtf); if (hData) { char* data = (char*)GlobalLock(hData); if (data) { printf("RTF clipboard contains: '%s'\n", data); GlobalUnlock(hData); } } else { printf("GetClipboardData failed\n"); } } else { printf("RTF format not available\n"); } CloseClipboard(); return 0; } ``` -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59257 Alex Henrie <alexhenrie24@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |alexhenrie24@gmail.com --- Comment #1 from Alex Henrie <alexhenrie24@gmail.com> --- So, the problem is only reproducible when copying text to the clipboard from Emacs, then pasting it into Wine? Copying and pasting from other applications works fine? Can you bisect the regression please? https://gitlab.winehq.org/wine/wine/-/wikis/Regression-Testing -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59257 Zeb Figura <z.figura12@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com --- Comment #2 from Zeb Figura <z.figura12@gmail.com> --- I tried this, and I got "emacs" once randomly, but every other time I tried running the program, I just got no RTF format. That's with emacs 30.2. With wine 10.0, I've gotten no RTF format every time I've tested, but I also only managed to get "emacs" once with 11.0. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59257 --- Comment #3 from Silas S. Brown <ssb22@cam.ac.uk> --- No RTF is correct: the Windows app always asks for RTF but when none is available it accepts plain text. The problem is it's sometimes getting text other than what should be on the clipboard, such as the string "emacs" (which in emacs source lisp/select.el is associated with the NAME atom) or other strings. As it's intermittent, I'm guessing it might be a timing issue and might therefore depend on the speed of your machine. You saw it only once and I saw it every time. I could try a bisect, but it may take a while: my first WINE compile took 11 hours to complete on this machine. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59257 --- Comment #4 from Silas S. Brown <ssb22@cam.ac.uk> --- Unfortunately, in addition to it taking 11 hours to build WINE on this machine (a 2018 i7-8850H laptop) even with 32-bit disabled in the build, the resulting built WINE is not able to read the RTF clipboard at all even when I put actual RTF on the clipboard (confirmed readable with wine-11). (And to make things more interesting, wine-11 running with the WINEPREFIX of the new build is also unable to read RTF. And the new build refuses to run with the WINEPREFIX of the production wine-11.) This makes it hard for me to do that bisection. There does not seem to be any relevant change given by `git log -p dlls/winex11.drv/clipboard.c` over the affected period. As the bug is timing related, it's not impossible that it already existed in wine 10 but wine 10's timings were different enough for it not to show up on my machine. It should be possible to test for this bug automatically if you don't mind Emacs (and X11) being required on the test machine. With that test.c compiled to a.exe you can run a script like this: emacs -q --eval='(progn (setq select-enable-clipboard t) (kill-new "Hello World"))' & EmacsPid=$! sleep 1 wine a.exe kill $EmacsPid When I ran that just now, I got: RTF clipboard contains: 'Silas S. Brown' instead of 'Hello World'. (Again, I have no idea where it's getting my name from as I have not put it on the clipboard.) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59257 --- Comment #5 from Silas S. Brown <ssb22@cam.ac.uk> --- (sorry, I should have said "instead of 'RTF format not available'" rather than "instead of 'Hello World'". As the problem appears random, the above script should probably be run multiple times and check that 'RTF format not available' happens every time.) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59257 Andrew Nguyen <arethusa26@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Regression SHA1| |d5dc6a234650a3baa349ce83679 | |ab8a3625a3f4c Status|UNCONFIRMED |NEW CC| |rbernon@codeweavers.com Keywords| |regression --- Comment #6 from Andrew Nguyen <arethusa26@gmail.com> --- Testing in a Ubuntu 24.04 VM, I had the most luck reproducing the reported issue (i.e., in my case, the test program can report the clipboard containing the string "Emacs" or "Test User") if I always start with a fresh Wine prefix before running the test script, although I suspect the incorrect behavior is very dependent on timing and perhaps something with the X11 window state. Regression testing identified the following commit: d5dc6a234650a3baa349ce83679ab8a3625a3f4c is the first bad commit commit d5dc6a234650a3baa349ce83679ab8a3625a3f4c Author: Rémi Bernon <rbernon@codeweavers.com> Date: Tue Jun 17 10:51:27 2025 +0200 server: Initialize global and user tables with some atoms. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=49195 I'm not 100% sure that this commit is the actual culprit, but it seemed to make reproducing the problem in my VM during the regression test very reliable. I'll attach a WINEDEBUG=+clipboard trace in case that helps. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59257 --- Comment #7 from Andrew Nguyen <arethusa26@gmail.com> --- Created attachment 80204 --> http://bugs.winehq.org/attachment.cgi?id=80204 +clipboard trace of unexpected clipboard behavior -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59257 --- Comment #8 from Rémi Bernon <rbernon@codeweavers.com> --- Thanks for the report, https://gitlab.winehq.org/wine/wine/-/merge_requests/10047 should fix this issue. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59257 Rémi Bernon <rbernon@codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|NEW |RESOLVED Fixed by SHA1| |0ed7e47d01975be9102b2a2c46e | |7e52ba889ddf7 --- Comment #9 from Rémi Bernon <rbernon@codeweavers.com> --- Should be fixed with 0ed7e47d01975be9102b2a2c46e7e52ba889ddf7 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59257 Alexandre Julliard <julliard@winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #10 from Alexandre Julliard <julliard@winehq.org> --- Closing bugs fixed in 11.3. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla