⚙️ 🤖 Drop nach Alacritty schlägt fehl — Upstream-Bug zwischen Chromium und winit #5

New issue

Open

opened 2026-08-30 11:49:22 +02:00 by holm · 0 comments

holm commented

2026-08-30 11:49:22 +02:00

Owner

Dimension	Bewertung	Einschätzung
Aufwand	`██░░░░░░░░`	Niedrig hier — die Reparatur liegt upstream, nicht in FlipDrop
Nutzen	`█████████░`	Sehr hoch — Drag&Drop in Anwendungen ist der Zweck des Tools
Bruchhäufigkeit	`██████████`	Immer — jeder Drop auf ein winit-Ziel schlägt fehl
Nachhaltigkeit	`███████░░░`	Hoch — mit dem winit-Release dauerhaft erledigt
Dringlichkeit	`███████░░░`	Hoch — Kernfunktion unbenutzbar, nur Clipboard-Behelf bleibt

Symptom: Eine FlipDrop-Kachel in ein Alacritty-Fenster zu ziehen (dort tmux mit einer TUI) bewirkt nichts. Kein Fehler, keine Reaktion.

Kreuzmessung (2026-08-30):

Test	Ergebnis
FlipDrop → `xdragon --target`	funktioniert, `text/uri-list` mit korrektem Pfad kommt an
`xdragon` → Alacritty/tmux	funktioniert
FlipDrop → Alacritty/tmux	schlägt fehl

Also weder die Quelle noch das Ziel für sich, sondern die Paarung.

Ursache (im Quellcode beider Seiten belegt): winit antwortet in XdndStatus/XdndFinished mit dem Action-Atom XdndActionPrivate (spec-konform, aber ungewöhnlich): https://github.com/rust-windowing/winit/blob/v0.30.13/src/platform_impl/linux/x11/dnd.rs#L72 — Chromiums AtomToDragOperation() kennt nur Copy/Move/Link und liefert für alles andere DragOperation::kNone; HandleMouseReleased() sendet XdndDrop nur bei != kNone. Chromium bricht den Drag damit still ab, das Ziel bekommt nie ein Drop-Event: https://chromium.googlesource.com/chromium/src/+/refs/heads/main/ui/base/x/x11_drag_drop_client.cc

Status upstream: Auf winit master behoben (Commit 156433e, PR #4571, auf XdndActionCopy geändert), aber in keinem Release enthalten — weder v0.30.13 noch v0.31.0-beta.2. Alacritty v0.17.0 hängt an winit 0.30.9 und ist betroffen.

Nicht quellseitig reparierbar: Electrons startDrag reicht nur {file, icon} durch; die MIME-Typen sind nicht beeinflussbar und ohnehin korrekt (text/uri-list ist genau das, was winit annimmt). Die Bruchstelle ist das Action-Atom, nicht der Typ. Ausgeschlossen wurde auch die Protokollversion: Alacritty meldet XdndAware = 5, Chromium verlangt genau 5.

Offen: Ein Gegentest mit kitty (nutzt kein winit, eigene X11-Anbindung) wurde vorbereitet, aber noch nicht durchgeführt — Ergebnis unbekannt, nicht raten.

Mögliche Wege (Entscheidung offen, holm): auf ein winit-Release mit dem Fix warten und Alacritty aktualisieren; ein anderes Terminal für Drop-Ziele verwenden, falls der kitty-Test positiv ausfällt; oder ein GTK-Helferfenster als Drag-Quelle nutzen (xdragon funktioniert nachweislich in beide Richtungen). Der eingebaute Klick→Clipboard-Weg bleibt als Behelf, ist aber ausdrücklich nicht das, was holm will — er will Dateien in Anwendungen hineinziehen.

🤖 angelegt von Claude w13 (API/Token holm)

| Dimension | Bewertung | Einschätzung | |---|---|---| | Aufwand | `██░░░░░░░░` | Niedrig hier — die Reparatur liegt upstream, nicht in FlipDrop | | Nutzen | `█████████░` | Sehr hoch — Drag&Drop in Anwendungen ist der Zweck des Tools | | Bruchhäufigkeit | `██████████` | Immer — jeder Drop auf ein winit-Ziel schlägt fehl | | Nachhaltigkeit | `███████░░░` | Hoch — mit dem winit-Release dauerhaft erledigt | | Dringlichkeit | `███████░░░` | Hoch — Kernfunktion unbenutzbar, nur Clipboard-Behelf bleibt | **Symptom:** Eine FlipDrop-Kachel in ein Alacritty-Fenster zu ziehen (dort tmux mit einer TUI) bewirkt nichts. Kein Fehler, keine Reaktion. **Kreuzmessung (2026-08-30):** | Test | Ergebnis | |---|---| | FlipDrop → `xdragon --target` | funktioniert, `text/uri-list` mit korrektem Pfad kommt an | | `xdragon` → Alacritty/tmux | funktioniert | | FlipDrop → Alacritty/tmux | schlägt fehl | Also weder die Quelle noch das Ziel für sich, sondern die Paarung. **Ursache (im Quellcode beider Seiten belegt):** winit antwortet in `XdndStatus`/`XdndFinished` mit dem Action-Atom `XdndActionPrivate` (spec-konform, aber ungewöhnlich): https://github.com/rust-windowing/winit/blob/v0.30.13/src/platform_impl/linux/x11/dnd.rs#L72 — Chromiums `AtomToDragOperation()` kennt nur Copy/Move/Link und liefert für alles andere `DragOperation::kNone`; `HandleMouseReleased()` sendet `XdndDrop` nur bei `!= kNone`. Chromium bricht den Drag damit still ab, das Ziel bekommt nie ein Drop-Event: https://chromium.googlesource.com/chromium/src/+/refs/heads/main/ui/base/x/x11_drag_drop_client.cc **Status upstream:** Auf winit master behoben (Commit 156433e, PR #4571, auf `XdndActionCopy` geändert), aber in keinem Release enthalten — weder v0.30.13 noch v0.31.0-beta.2. Alacritty v0.17.0 hängt an winit 0.30.9 und ist betroffen. **Nicht quellseitig reparierbar:** Electrons `startDrag` reicht nur `{file, icon}` durch; die MIME-Typen sind nicht beeinflussbar und ohnehin korrekt (`text/uri-list` ist genau das, was winit annimmt). Die Bruchstelle ist das Action-Atom, nicht der Typ. Ausgeschlossen wurde auch die Protokollversion: Alacritty meldet `XdndAware = 5`, Chromium verlangt genau 5. **Offen:** Ein Gegentest mit `kitty` (nutzt kein winit, eigene X11-Anbindung) wurde vorbereitet, aber noch nicht durchgeführt — Ergebnis unbekannt, nicht raten. **Mögliche Wege (Entscheidung offen, holm):** auf ein winit-Release mit dem Fix warten und Alacritty aktualisieren; ein anderes Terminal für Drop-Ziele verwenden, falls der kitty-Test positiv ausfällt; oder ein GTK-Helferfenster als Drag-Quelle nutzen (`xdragon` funktioniert nachweislich in beide Richtungen). Der eingebaute Klick→Clipboard-Weg bleibt als Behelf, ist aber ausdrücklich nicht das, was holm will — er will Dateien in Anwendungen hineinziehen. > 🤖 angelegt von Claude w13 (API/Token holm)

holm added the

labels

2026-08-30 11:49:27 +02:00

holm referenced this issue from a commit

2026-08-30 11:49:43 +02:00

docs: Drop nach Alacritty als Upstream-Einschränkung dokumentiert