fix: Linux/WebKitGTK image intake — file picker, clipboard paste, and drop-zone claim

[EthanCheung-gh]

Summary

On Linux (WebKitGTK 2.52.x), images could not be inserted into the chat
composer at all: the "Add image" picker silently dropped every selection,
and pasting a screenshot did nothing. Both paths are now fixed and verified
on real hardware; a third, partial improvement un-claims the composer drop
zone for unidentified drags.

All three failures are WebKitGTK-specific engine gaps, not regressions in
this repo — WebView2 and WKWebView never hit them, which is why they went
unnoticed upstream.

Root causes (probed on WebKitGTK 2.52.6 / GNOME 50.1 / Wayland)

1. File picker — detached <input type=file> never receives change.
   The picker was created via createElement and clicked without being
   mounted. WebKitGTK opens the native chooser, the user picks a file, and
   the engine never fires change on the detached element — the selection
   is silently dropped (no thumbnail, no log, no error). Verified with a
   minimal GTK+WebKit probe: attached inputs fire change; detached ones
   do not.

2. Paste — DataTransfer is permanently empty.
   WebKitGTK delivers paste events with zero items and zero types
   (even for text), while getData() keeps working — so text paste works
   but the in-page file branch can never see an image. The Async Clipboard
   API (navigator.clipboard.read()) is not a way out either: its promise
   never settles on this engine. Pasted images were simply unreachable
   from the page.

3. Drag & drop — the composer drop zone claims unidentified drags.
   ContextDropZone called preventDefault on every dragenter/dragover.
   On WebKitGTK an OS file drag reports no types at all, so the claim
   swallowed the drag while the in-page handler found nothing to handle.
   (Partial fix — see "Known limitations".)

The commits

fix(web-ui): mount the image picker so WebKitGTK delivers change

Mounts the picker offscreen (position: fixed; left: -9999px —
display: none is deliberately avoided because some WebKit builds refuse
to open a chooser for it) and reclaims the node on both the change path
and the cancel path (one-shot window focus listener).

fix(desktop): read pasted clipboard images through the host on WebKitGTK

Adds a get_clipboard_image desktop command that reads the clipboard via
the same wl-paste/xclip tools already used by get_clipboard_files,
sniffs PNG/JPEG magic bytes, and returns base64 pixels. The composer now
listens for paste directly and — only when the webview reported zero
types (the WebKitGTK shape; WebView2/WKWebView deliver images in-band and
keep their existing path) — asks the host for the image and reuses the
existing clipboard-image intake, so limits and error reporting are
identical. Registers the command in the remote-surface registry
(LocalOnly) and in the attachments capability evidence; capability
artifacts regenerated.

fix(web-ui): stop claiming empty-typed drags in the composer drop zone

The zone now claims only drags it can positively identify and handle:
internal context payloads, typed non-file drags, and Files drags when a
DOM file handler is actually provided (the Windows desktop runtime).
Empty-typed drags stay unclaimed and keep flowing to the pane-level
native drop path.

Verification

Real device: Ubuntu 26.04, GNOME 50.1, Wayland, WebKitGTK 2.52.6, deb
install shape.

Path	Before	After
+ → Add image → picker	silently dropped	✅ attaches (select and cancel paths)
Ctrl+V screenshot paste	nothing	✅ attaches
Drop file on conversation pane	worked	still works
Drop file directly on composer	silently dropped	⚠️ still not attaching (see below)

• Automated end-to-end through the embedded WebDriver of an isolated
  desktop instance: synthetic empty-typed paste on the composer →
  host clipboard read → attachment thumbnail rendered.
• Focused suites: web-ui 24/24 (new regression tests for the mounted
  picker, the paste fallback gating, and the unclaimed drag), desktop
  clipboard API 14/14, product-domains registry 40/40,
  check:core-boundaries green, capabilities:generate regenerated.

Known limitations

• Dropping an OS file directly on the composer still does not attach
  on WebKitGTK: a document-level dragover preventDefault keeps the
  subtree claimed and the native window drop handler never sees the
  release over the composer. The third commit removes the zone's own
  silent swallow and is a step toward the fix, but full on-composer
  native drops need follow-up at the WebKitGTK/wry interaction level.
• jsdom cannot reproduce any of the three engine gaps (detached-input
  change fires fine there; DataTransfer shape is synthetic), so the
  new tests lock in the wiring and the gating decisions, and the real
  verification is the on-device matrix above.

Platform impact

No behavior change on Windows or macOS: WebView2/WKWebView populate
DataTransfer and deliver change for detached inputs, so the fallback
paths never trigger and the in-band paths are untouched.

[kev1n77]

Thanks for the fix.

Before merging, please address the remaining integration issues:

• Missing wl-paste/xclip currently results in a silent empty response. Please return an explicit error/unsupported state or ensure these dependencies are packaged.
• Use the repository’s process-manager abstraction instead of calling std::process::Command directly.
• Please rebase/merge the latest main and resolve the current conflicts.
• Please attach screenshots or a short recording showing the file-picker and clipboard-image flows on Linux/WebKitGTK.

After these are addressed, this should be ready for another review.

[EthanCheung-gh]

1.
2.

All four points addressed — force-pushed as 09710bd9e → 610801ce4 (4 commits, rebased onto current main).

1. Missing wl-paste/xclip is now an explicit unsupported state. get_clipboard_image distinguishes "clipboard holds no image" from "neither reader tool could be spawned". The latter returns a clipboard_image_unsupported: error, which the composer surfaces as a localized warning (input.clipboardImageToolsUnavailable, en-US/zh-CN/zh-TW; i18n:audit passes) instead of silently doing nothing. We chose the explicit error over packaging the tools: wl-clipboard/xclip pull in display-stack dependencies that don't belong in the deb Depends for an optional fallback path.

2. Process-manager abstraction. All Linux clipboard tool spawns — the new image readers and the pre-existing get_clipboard_files uri-list helpers in the same module — now go through openbitfun_core::util::process_manager::create_command instead of bare std::process::Command. The untouched macos_clipboard osascript call predates this PR; happy to convert it in a follow-up.

3. Rebased onto latest main (8471a65cd). Conflicts were limited to generated capability artifacts; resolved by taking main's versions and regenerating with capabilities:generate from the merged sources.

4. Screenshots on Ubuntu 26.04 / GNOME Wayland / WebKitGTK 2.52.6 (attached):

• Screenshot 1 — "＋" → Add image → file-picker selection renders as an attachment thumbnail.
• Screenshot 2 — screenshot into the clipboard → Ctrl+V on the composer → pasted image attaches through the host clipboard read.

Focused suites: desktop clipboard API 14/14, web-ui intake/drop-zone tests 9/9. As with #3123, fork-PR checks need a maintainer workflow approval to run.