macOS clipboard writes reinterpret non-ASCII UTF-8 bytes as MacRoman

[Cretezy]

Is your issue REALLY a bug?

• My issue is indeed a bug.
• I am not filing a question or feature request.

Is there an existing issue for this?

• I searched open and closed issues in iced-rs/iced, as well as issues in hecrj/window_clipboard, using macOS, clipboard, Unicode, non-ASCII, encoding, and clipboard_macos terms. I found no matching report.

Is this issue related to iced?

• Yes. The text passed to Iced is a valid Rust UTF-8 String, and the corruption happens when it is written through Iced's macOS clipboard path.

What happened?

On macOS, writing non-ASCII text through iced::clipboard::write corrupts it on the system clipboard.

Minimal example:

iced::clipboard::write::<Message>("→".to_owned())

After pasting into another application:

→  becomes  ‚Üí

This is a byte-for-byte encoding signature: → is UTF-8 E2 86 92, while interpreting those three bytes individually as MacRoman produces ‚Üí.

I encountered this in a terminal emulator in two independent user-facing flows:

1. Copying selected terminal text with a copy keybind.
2. Handling an OSC 52 clipboard-store request.

Both flows produce the correct Rust String and converge on iced::clipboard::write, and both exhibit the same corruption on macOS. Selection extraction tests already verify Unicode scalars, wide characters, and combining characters before the Iced clipboard boundary.

Relevant resolved dependency versions from the application using Iced 0.14:

iced 0.14.0
iced_winit 0.14.0
window_clipboard 0.5.1
clipboard_macos 0.1.1
objc2 0.5.2 (through clipboard_macos)
objc2-foundation 0.2.2 (through clipboard_macos)

The current macOS path is:

iced::clipboard::write
  -> iced_winit::Clipboard::write
  -> window_clipboard::ClipboardProvider::write
  -> clipboard_macos::Clipboard::write

An application-level workaround is to bypass that writer on macOS and write an NSString explicitly as NSPasteboardTypeString:

let pasteboard = NSPasteboard::generalPasteboard();
pasteboard.clearContents();
let text = NSString::from_str(text);
let string_type = unsafe { NSPasteboardTypeString };
pasteboard.setString_forType(&text, string_type);

This workaround type-checks for aarch64-apple-darwin against objc2 0.6.4 and objc2-app-kit / objc2-foundation 0.3.2. I am including it to narrow the likely boundary, not to assert the precise upstream fix.

What is the expected behavior?

The clipboard must preserve the Unicode string exactly. Writing → should paste as →, and other non-ASCII characters should round-trip unchanged.

Version

crates.io release (iced 0.14.0)

Operating System

macOS

Do you have any log output?

There is no relevant log output; the clipboard operation reports no error.

[edwloef]

The master branch has switched from window_clipboard to arboard, does that fix things?