mirror of
https://github.com/bulwarkmail/webmail.git
synced 2026-10-31 08:13:50 +00:00
dealerweb
04996a3af1
Clicking an address in the app's own chrome - the recipient card, the contact sidebar, the contact details - handed a mailto: URL to the OS mail handler. In a webmail client that goes nowhere: the browser asks which application should open the link, and the message is composed somewhere else, if at all. Only users who registered Bulwark itself as their system mailto handler got a usable result, and even then via a detour through the OS into a new tab. A new MailtoLink component sends the click to the built-in composer instead. It stays a real anchor with an href, so "Copy email address", middle click and assistive technology keep working; only the plain left click is redirected, and only when a listener takes it - otherwise the browser's own behaviour still applies. Modified clicks are left alone. The request reaches the mail page through a window event, the way `bulwark:rate-limit-blocked` already does, rather than threading a callback through three component levels and five call sites. It goes to openMailtoDraft rather than the protocol path: an in-app click carries its own context - the account being read - so the account picker that an external mailto: needs would only get in the way here. Message content is deliberately untouched. Plain text bodies render into the main document rather than the sandboxed frame and their sanitizer permits mailto:, so a document-wide interceptor would have swept up untrusted links too; a component cannot be reached from message HTML at all.