⚙️ 🤖 ABS-Webview-Machbarkeit bestätigt (Login + Play im Electron-Fenster) #2

New issue

Closed

opened 2026-08-24 13:05:12 +02:00 by holm · 1 comment

holm commented

2026-08-24 13:05:12 +02:00

Owner

Dimension	Bewertung	Einschätzung
Aufwand	`███░░░░░░░`	Niedrig-mittel — Spike bereits gelaufen, echter Player-Code fehlt noch
Nutzen	`██████████`	Sehr hoch — entscheidet zwischen "ABS-Webplayer einbetten" und "eigenen Player nachbauen"
Bruchhäufigkeit	`█░░░░░░░░░`	Einmalig — Machbarkeits-Frage
Nachhaltigkeit	`████████░░`	Hoch — legt die Player-Architektur fest
Dringlichkeit	`███████░░░`	Hoch — blockiert den eigentlichen Player-Code

Frage aus Issue #1

Scope-Punkt 3 sah vor: zuerst versuchen, ABS' eigenen Web-Player in einem Chromium-<webview>/Electron-Fenster zu steuern (als "unwahrscheinlich" eingeschätzt), sonst eigener Nachbau.

Befund: funktioniert, mit einem Selbstschuss auf dem Weg

Electron-BrowserWindow laedt https://audiothek.mueller.network/ direkt (eigenes userData, komplett getrennt von Holms normalem Chromium-Profil). Holms laufendes Chromium hat KEINEN --remote-debugging-port offen -- das global nachzuruesten haette CDP-Kontrolle ueber alle seine App-Fenster (Forgejo, EGroupware, Plex, ...) geoeffnet. Das eigene Electron-Fenster braucht diesen Umweg nicht, es ist sein eigener Chromium-Unterbau.

Mit Holm live durchgespielt: Login (Username/Passwort + 2FA) und Play funktionieren im echten Nutzertest. <audio>-Element ist per executeJavaScript auslesbar (paused:false, currentTime laeuft in Echtzeit hoch, auch nach Fokusverlust des Fensters).

Sackgasse unterwegs: Ein zwischenzeitlich als "2FA-Feld nicht klickbar" gemeldetes Problem war kein WM/Electron-Fokus-Bug (erste Hypothese: i3 bedient WM_TAKE_FOCUS aus WM_PROTOCOLS nicht) -- win.isFocused() lieferte durchgehend true, die Hypothese war falsch. Tatsaechliche Ursache: eine Diagnose-Zeile im Spike selbst schrieb alle 6s testweise 424242 ins Feld und ueberschrieb damit jede echte Holm-Eingabe. Nach Entfernen lief Login sauber durch. Lehre: Diagnose-Code, der selbst schreibend in den Testgegenstand eingreift, zuerst als Fehlerquelle ausschliessen, bevor Infrastruktur-Hypothesen (WM/Compositor) verfolgt werden.

Konsequenz fuer die Player-Architektur

Weg 3 (ABS-Webplayer einbetten statt nachbauen) ist die Basis fuer den eigentlichen Player-Code: eigenes Electron-Fenster laedt ABS, Play/Pause/Seek laeuft ueber ABS' eigene UI bzw. executeJavaScript gegen das <audio>-Element, kein eigener Streaming-/Decoding-Code noetig.

Was in diesem Commit liegt

spikes/abs-spike.js — bereinigte, dokumentierte Fassung (Diagnose-Ueberschreib-Bug entfernt)

🤖 angelegt von Claude v00 (API/Token holm)

| Dimension | Bewertung | Einschätzung | |---|---|---| | Aufwand | `███░░░░░░░` | Niedrig-mittel — Spike bereits gelaufen, echter Player-Code fehlt noch | | Nutzen | `██████████` | Sehr hoch — entscheidet zwischen "ABS-Webplayer einbetten" und "eigenen Player nachbauen" | | Bruchhäufigkeit | `█░░░░░░░░░` | Einmalig — Machbarkeits-Frage | | Nachhaltigkeit | `████████░░` | Hoch — legt die Player-Architektur fest | | Dringlichkeit | `███████░░░` | Hoch — blockiert den eigentlichen Player-Code | ## Frage aus Issue [#1](https://forgejo.mueller.network/holm.tools.public/playzen/issues/1) Scope-Punkt 3 sah vor: zuerst versuchen, ABS' eigenen Web-Player in einem Chromium-`<webview>`/Electron-Fenster zu steuern (als "unwahrscheinlich" eingeschätzt), sonst eigener Nachbau. ## Befund: funktioniert, mit einem Selbstschuss auf dem Weg Electron-`BrowserWindow` laedt `https://audiothek.mueller.network/` direkt (eigenes `userData`, komplett getrennt von Holms normalem Chromium-Profil). Holms laufendes Chromium hat KEINEN `--remote-debugging-port` offen -- das global nachzuruesten haette CDP-Kontrolle ueber alle seine App-Fenster (Forgejo, EGroupware, Plex, ...) geoeffnet. Das eigene Electron-Fenster braucht diesen Umweg nicht, es ist sein eigener Chromium-Unterbau. Mit Holm live durchgespielt: Login (Username/Passwort + 2FA) und Play funktionieren im echten Nutzertest. `<audio>`-Element ist per `executeJavaScript` auslesbar (`paused:false`, `currentTime` laeuft in Echtzeit hoch, auch nach Fokusverlust des Fensters). **Sackgasse unterwegs:** Ein zwischenzeitlich als "2FA-Feld nicht klickbar" gemeldetes Problem war kein WM/Electron-Fokus-Bug (erste Hypothese: i3 bedient `WM_TAKE_FOCUS` aus `WM_PROTOCOLS` nicht) -- `win.isFocused()` lieferte durchgehend `true`, die Hypothese war falsch. Tatsaechliche Ursache: eine Diagnose-Zeile im Spike selbst schrieb alle 6s testweise `424242` ins Feld und ueberschrieb damit jede echte Holm-Eingabe. Nach Entfernen lief Login sauber durch. Lehre: Diagnose-Code, der selbst schreibend in den Testgegenstand eingreift, zuerst als Fehlerquelle ausschliessen, bevor Infrastruktur-Hypothesen (WM/Compositor) verfolgt werden. ## Konsequenz fuer die Player-Architektur Weg 3 (ABS-Webplayer einbetten statt nachbauen) ist die Basis fuer den eigentlichen Player-Code: eigenes Electron-Fenster laedt ABS, Play/Pause/Seek laeuft ueber ABS' eigene UI bzw. `executeJavaScript` gegen das `<audio>`-Element, kein eigener Streaming-/Decoding-Code noetig. ## Was in diesem Commit liegt - `spikes/abs-spike.js` — bereinigte, dokumentierte Fassung (Diagnose-Ueberschreib-Bug entfernt) > 🤖 angelegt von Claude v00 (API/Token holm)

holm added the

Kind/Feature

Priority/High

labels

2026-08-24 13:05:17 +02:00

holm referenced this issue from a commit

2026-08-24 13:05:29 +02:00

feat: ABS-Webview-Machbarkeit bestätigt

holm commented

2026-08-24 13:05:39 +02:00

Author

Owner

Erledigt — Commit 9669c14 auf dev gepusht.

Beleg: Live-Test mit Holm -- Login (Username/Passwort + 2FA) und Play im Electron-Fenster erfolgreich. <audio>-Poll zeigte paused:false, currentTime lief in Echtzeit hoch (3.6s -> 18.7s), auch nach Fokusverlust des Fensters. Damit ist die Architektur-Entscheidung fuer den Player getroffen: ABS-Webplayer einbetten statt eigenen Nachbau.

🤖 Kommentar von Claude v00 (API/Token holm)

**Erledigt** — Commit [`9669c14`](https://forgejo.mueller.network/holm.tools.public/playzen/commit/9669c14cf7d9d6f60e2649a59fad9ff180fd3976) auf `dev` gepusht. Beleg: Live-Test mit Holm -- Login (Username/Passwort + 2FA) und Play im Electron-Fenster erfolgreich. `<audio>`-Poll zeigte `paused:false`, `currentTime` lief in Echtzeit hoch (3.6s -> 18.7s), auch nach Fokusverlust des Fensters. Damit ist die Architektur-Entscheidung fuer den Player getroffen: ABS-Webplayer einbetten statt eigenen Nachbau. > 🤖 Kommentar von Claude v00 (API/Token holm)

holm closed this issue

2026-08-24 13:05:39 +02:00

holm referenced this issue

2026-08-24 13:25:03 +02:00

✨ 🤖 v0.1: Player mit Hide-to-Systray + Cloudron-SSO-WebAuthn-Fix #3