> ## Content Index
> Fetch the complete content index at: https://aresa.me/llms.txt
> Use this file to discover other available public pages before exploring further.

# The Clipboard Fallback That Swallowed Real File Paste Events
- URL: https://aresa.me/walz-clipboard-fallback-swallowed-file-paste/
- Published: 2026-08-26T20:39:50.000Z
- Updated: 2026-08-26T20:39:50.000Z
- Description: Walz's clipboard bridge intercepted paste whenever it saw a file-like MIME type, even when WebKit had already supplied real File objects to the trusted event.
- Author: Alex Oleshkevich
- Tags: Dev Log, Walz

Walz added a native clipboard fallback for cases where WebKit could not expose copied files, then used it too broadly. When a paste event already contained real `File` objects, the bridge canceled that trusted event and replaced it with a synthetic one that WhatsApp could ignore.

The fix was a smaller interception rule: use the native fallback only when the clipboard advertises file-like data but the browser event contains no actual files.

## MIME markers did not mean the browser had failed

The original code looked for entries such as `Files` or image MIME types in `clipboardData.types`. If it found one, it called `preventDefault`, asked the Tauri backend for clipboard files, and dispatched a replacement paste event.

That treated a hint about clipboard content as proof that WebKit had failed. In successful cases, `clipboardData.files` was already populated or `clipboardData.items` contained entries whose `kind` was `file`. The bridge discarded the highest-quality event precisely when it had the data the page expected.

The browser event also carried trust that JavaScript cannot manufacture. The [Clipboard API specification](https://www.w3.org/TR/clipboard-apis/?ref=aresa.me) constrains synthetic clipboard events and their interaction with the system clipboard. A constructed event may contain useful data, but a web application is free to distinguish it from user-generated input.

## The guard now prefers native delivery

Walz's injected script first checks two concrete signals:

```javascript
clipboardData.files.length > 0
clipboardData.items.some((item) => item.kind === "file")
```

If either is true, the handler returns without preventing the default action. WebKit and the page receive the original trusted event.

Only when file-like MIME markers exist without browser-provided file items does Walz call its native `get_clipboard_files` command and construct a fallback payload. The fallback remains available for the environment that motivated it, but it no longer competes with a successful platform path.

## Fallbacks should prove the primary path is absent

Compatibility bridges often begin with a broad capability test: if the clipboard looks like it contains a file, use the native bridge. That is the wrong side of the decision. The question is whether the primary path produced the specific object the consumer needs.

For Walz, the order is now:

1. Preserve a trusted event containing real file items.
2. Use the bridge when the event advertises files but supplies none.
3. Leave ordinary text and HTML paste alone.

Syntax checks, Rust tests, and package builds validated the change, but the captured work stopped before installing the package and repeating the paste in the live target. That limitation is part of the result. The code now expresses the correct event policy; deployment and user-level confirmation remain a separate boundary.