[Bug 59616] New: CF_HDROP export to text/uri-list incorrectly URL-encodes slashes ('/'), breaking file pasting in native Linux file dialogs

[WineHQ Bugzilla]

http://bugs.winehq.org/show_bug.cgi?id=59616

            Bug ID: 59616
           Summary: CF_HDROP export to text/uri-list incorrectly
                    URL-encodes slashes ('/'), breaking file pasting in
                    native Linux file dialogs
           Product: Wine
           Version: 11.5
          Hardware: x86-64
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: -unknown
          Assignee: [e-mail]
          Reporter: [e-mail]
      Distribution: ---

Component: x11drv (not in the list)

When copying a file from a Wine application (e.g., Wine Explorer, Total
Commander) and pasting it into a native Linux application's "File -> Open"
dialog (e.g., KDE/Qt), the pasted URI is completely broken. 

The path is pasted with URL-encoded directory separators (e.g.,
`file:///home%2Fuser%2F.wine%2Fdosdevices%2Fc%3A%2Ffile.jpg`). Native Linux
file dialogs fail to open this because they interpret `%2F` as a literal
character in a filename, not as a directory separator.

Steps to Reproduce:
1. Open any file manager inside Wine.
2. Select a file and press Ctrl+C (copying it to the clipboard).
3. Open a native Linux application (e.g., Kate, Firefox, Telegram).
4. Open the "File -> Open" dialog or trigger a paste action.
5. Press Ctrl+V in the filename/path field.

Actual Result:
The pasted string is:
`file:///home%2Fuser%2F.wine%2Fdosdevices%2Fc%3A%2Ffile.jpg`
The Linux app throws a "File not found" error.

Expected Result:
The pasted string should be: `file:///home/user/.wine/dosdevices/c:/file.jpg`
(Spaces and non-ASCII characters should still be encoded, but structural
delimiters like '/' and ':' must be preserved).

Root Cause Analysis:
The bug is located in `dlls/winex11.drv/clipboard.c`, inside the `export_hdrop`
function.
There is a comment in the code that says:
/* URL encode everything - unnecessary, but easier/lighter than linking in
shlwapi, and can't hurt */

However, "encoding everything" *does* hurt. By encoding the forward slash
('/'), the code violates RFC 3986 section 3.3, which states that the path
component consists of segments separated by slash ('/') characters. When the
slash itself is percent-encoded, URI parsers treat the entire path as a single
filename segment.

Proposed Fix / Patch:
We need to preserve unreserved characters and structural delimiters (like '/',
':', '.', '-', '_') while still encoding spaces and Unicode characters (e.g.,
Cyrillic) to maintain valid URIs.

Here is the tested and working replacement for the encoding loop in
`dlls/winex11.drv/clipboard.c`:

/* URL encode, but preserve structural delimiters and alphanumeric chars (RFC
3986) */
for (u = 1; unixFilename[u]; u++)
{
    char ch = unixFilename[u];
    if (ch == '/' || ch == ':' || ch == '.' || ch == '-' || ch == '_' || ch ==
'~' ||
       (ch >= 'a' && ch <= 'z') || (ch >= 'A' && ch <= 'Z') || (ch >= '0' && ch
<= '9'))
    {
        textUriList[next++] = ch;
    }
    else
    {
        static const char hex_table[] = "0123456789abcdef";
        textUriList[next++] = '%';
        textUriList[next++] = hex_table[(unsigned char)ch >> 4];
        textUriList[next++] = hex_table[ch & 0xf];
    }
}

I have compiled and tested this patch locally on KDE Plasma (Wayland/Xwayland).
It perfectly resolves the issue: files with spaces/Cyrillic are still properly
encoded (e.g., `%20`), but slashes are preserved, allowing native Linux UI to
parse and open the files instantly via 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.