Skip to content

feat(cliprdr): advertise Preferred DropEffect alongside FileGroupDescriptorW#1301

Open
clintcan wants to merge 1 commit into
Devolutions:masterfrom
clintcan:feat/cliprdr-preferred-drop-effect
Open

feat(cliprdr): advertise Preferred DropEffect alongside FileGroupDescriptorW#1301
clintcan wants to merge 1 commit into
Devolutions:masterfrom
clintcan:feat/cliprdr-preferred-drop-effect

Conversation

@clintcan
Copy link
Copy Markdown

initiate_file_copy now advertises both FileGroupDescriptorW and Preferred DropEffect (CFSTR_PREFERREDDROPEFFECT) in the FormatList, and handle_format_data_request short-circuits a request for the latter with DROPEFFECT_COPY (0x00000001 LE).

Changes

  • New constant: ClipboardFormatName::PREFERRED_DROP_EFFECT = "Preferred DropEffect".
  • New field: Cliprdr::local_drop_effect_format_id — mirrors local_file_list_format_id in lifecycle (set in initiate_file_copy, cleared on FormatListResponse::Fail and at the top of initiate_copy).
  • Distinct private-range format ID (0xC0FD) — the wire only cares about the format name; the ID just needs to be locally unique so the request can be routed.
  • No backend trait changes — the response is fixed (DROPEFFECT_COPY, matching the function's name) and served inline, so backends don't have to learn about the format.

Why

Windows Explorer pairs CFSTR_PREFERREDDROPEFFECT with the file formats locally; together they label the operation as a copy. When both are present, Explorer engages its shell file-copy machinery on paste (with native progress UI). Without PreferredDropEffect, Explorer falls back to a plain synchronous IStream read.

Use case / verification

Used in macrdp (a Rust RDP server for macOS) to deliver the standard "copy a file from the remote into local Windows Explorer" UX. Verified end-to-end on real mstsc.

The companion FD_PROGRESSUI flag (#1299) is what actually triggers the native progress dialog; PreferredDropEffect provides the operation-semantics label Windows expects to see alongside the file descriptor for a clipboard file paste. Either change is independently useful, but the user-visible "native progress dialog" UX requires both.

Related

…riptorW

`initiate_file_copy` now advertises BOTH `FileGroupDescriptorW` AND
`Preferred DropEffect` (`CFSTR_PREFERREDDROPEFFECT`) in the same
FormatList, and `handle_format_data_request` short-circuits a
FormatDataRequest for the latter with `DROPEFFECT_COPY` (0x00000001 LE)
without bothering the backend.

- Added `ClipboardFormatName::PREFERRED_DROP_EFFECT = "Preferred DropEffect"`.
- Added `Cliprdr::local_drop_effect_format_id` (mirrors
  `local_file_list_format_id` in lifecycle: set in `initiate_file_copy`,
  cleared on FormatListResponse::Fail and at the top of `initiate_copy`).
- Picked a distinct private-range format ID (`0xC0FD`) — the wire only
  cares about the format *name*; the ID just needs to be locally unique
  so the request can be routed.

No backend trait changes — the response is fixed (DROPEFFECT_COPY,
matching the function's name) and served inline, so backends don't have
to learn about the format.

### Why

Windows Explorer pairs `CFSTR_PREFERREDDROPEFFECT` with the file
formats locally; together they label the operation as a *copy*. When
both are present, Explorer engages its shell file-copy machinery on
paste (with native progress UI). Without `PreferredDropEffect`,
Explorer falls back to a plain synchronous IStream read.

### Use case

Used in https://github.com/clintcan/macrdp to deliver the standard
"copying a file from the remote into local Windows Explorer" UX. The
companion FD_PROGRESSUI flag (in a separate PR) is what actually
triggers the native progress dialog; `PreferredDropEffect` provides
the operation-semantics label Windows expects to see alongside the
file descriptor for a clipboard file paste.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant