mailto- und tel-Links öffnen jetzt auch aus dem Web-Reader

[JumpLink]

Worum es geht: In der Web-Version läuft der Artikel in einem abgeschotteten iframe (sandbox="allow-same-origin allow-scripts", #269). Ein Klick auf eine E-Mail-Adresse oder Telefonnummer im Artikeltext hat dort bislang nichts ausgelöst: Der Browser hat den Navigationsversuch des abgeschotteten Frames still verworfen, ohne Fehlermeldung für die Leserin. Auf dem Handy funktioniert das seit jeher, weil dort die native WebView den Aufruf selbst an das Betriebssystem weiterreicht.

Was sich ändert: Der Klick-Handler des Web-Readers fängt den Klick weiterhin ab und entscheidet wie bisher über readerClickAction(). Für mailto: und tel: öffnet er die Adresse jetzt aber aus dem Eltern-Fenster der App statt sie dem Frame zu überlassen, denn das Eltern-Fenster unterliegt keiner Sandbox. Am iframe selbst ändert sich nichts: sandbox="allow-same-origin allow-scripts" bleibt exakt wie zuvor, es kommt weder allow-popups noch ein allow-top-navigation-* hinzu.

Closes #274

Technische Details

Gemessen: Google Chrome 153.0.8010.47 über playwright-core (Version 1.63.0), headless, aus einem Scratch-Verzeichnis heraus (/usr/bin/google-chrome). Zwei Schritte:

1. Eine originalgetreue Nachbildung des iframes (identisches sandbox, identische READER_CSP, identische Klick-Logik aus readerClickAction) mit einem mailto:- und einem tel:-Link. Vor der Änderung: Chrome loggt
   Navigation to external protocol blocked by sandbox, because it doesn't contain any of: 'allow-top-navigation-to-custom-protocols', 'allow-top-navigation-by-user-activation', 'allow-top-navigation', or 'allow-popups'.
   CDP (Page.frameRequestedNavigation) zeigt den Navigationsversuch im SANDBOXED Frame, kein Popup, keine Top-Level-Navigation, nichts öffnet sich.
2. Mit dem in diesem PR umgesetzten Verhalten (click im Frame abbrechen, window.location.href im Eltern-Fenster setzen): keine Sandbox-Fehlermeldung mehr, Chrome loggt stattdessen Launched external handler for 'mailto:redaktion@correctiv.org'., und CDP zeigt die Navigation jetzt im TOP-Frame, nicht mehr im Sandbox-Frame.

Zusätzlich am echten Build verifiziert: npm run build:web, /gallery-Route (apps/mobile/src/gallery/catalogue.tsx) mit einem temporär eingefügten mailto:-Link und einem onNavigate, das wie die echte artikel.tsx mailto/tel durchlässt. Dieselbe Launched external handler-Meldung, derselbe reale, kompilierte ReaderView.web.tsx-Code. Die Teständerungen an gallery/catalogue.tsx und gallery/fixtures.ts wurden vor dem Commit wieder verworfen (git checkout), sie sind nicht Teil dieses PRs.

Warum die Sandbox unangetastet bleibt: Chromes eigene Fehlermeldung nennt allow-top-navigation-to-custom-protocols als Lösung für genau diesen Fall. Trotzdem nicht verwendet, weil ein Sandbox-Flag an jeden im Frame verschachtelten Frame vererbt wird (ADR 0065 §4/§5). Das Flag hier zu setzen würde es auch jedem Embed geben, genau die Reichweite, die allowsFrameLoad() einem Embed auf dem Handy verweigert. allow-popups ist noch weiter gefasst, ein Dauer-Recht, überhaupt ein Fenster zu öffnen. Stattdessen übernimmt jetzt das Eltern-Fenster das Öffnen, das von Haus aus keiner Sandbox unterliegt, keine neue Berechtigung, nur ein anderer Ort für denselben Aufruf.

Geänderte Dateien:

• apps/mobile/src/components/reader/ReaderView.web.tsx: handleClick bricht den Klick bei 'let-through' jetzt ebenfalls ab und setzt window.location.href im Eltern-Fenster auf die aufgelöste Adresse.
• apps/mobile/src/lib/articles/readerNavigation.ts: neue Funktion resolveReaderLink(), dieselbe URL-Auflösung, die readerClickAction() intern schon macht, jetzt auch für den Host verfügbar, damit die Auflösung nicht zweimal geschrieben wird. Die reine Entscheidungslogik in readerClickAction() selbst ist unverändert.
• apps/mobile/__tests__/reader-navigation.test.ts: Tests für resolveReaderLink().

Was unverändert bleibt und warum: classifyReaderLink(), allowsFrameLoad() und die native ReaderView.tsx (WebView, kein Klick-Handler) sind nicht betroffen, das Problem ist Web-spezifisch, auf dem Handy hat es nie bestanden. readerClickAction()s Signatur und Rückgabewerte ('prevent' | 'let-through') bleiben unverändert, damit bestehende Aufrufer nicht anfassen mussten.

Geprüft: npm run check (Typecheck, oxlint, oxfmt, alle Tests) lokal grün, ebenso über den Push-Hook. Keine sichtbare UI-Änderung, daher kein Screenshot in screens/evidence/.

Nicht geprüft: Ein echter Mailclient/Telefon-Handler auf diesem Linux-Testrechner (Chrome loggt Launched external handler für mailto:, für tel: ohne registrierten Handler auf der Maschine keine entsprechende Zeile, aber auch keine Sandbox-Fehlermeldung, beides läuft über denselben, jetzt ungehinderten Weg). Firefox 155.0 ist auf dieser Maschine zwar installiert, aber playwright-core steuert nur seinen eigenen, gepatchten Firefox-Build an; ein Versuch, den System-Firefox darüber zu starten, schlägt fehl (Failed to launch the browser process), daher kein Firefox-Test.

🤖 Generated with Claude Code