feat(emailPreview): i18n fix, open links in new tab, HTML/text switcher#246
Conversation
Picks up the upload-validator removal from encryption4all/postguard-js#87 (released as 2.0.1 via the follow-up fix: commit in #88), which unblocks the staging email-preview modal flow — passing `onUploadInit` no longer throws `TypeError: unknown option "onUploadInit"`.
The staging email-preview modal calls
\`\$_('filesharing.emailPreview.*')\`, but the keys had been added one
level deeper at \`filesharing.encryptPanel.emailPreview.*\` — the modal
therefore rendered the raw key paths instead of the translated strings.
The modal isn't part of the encrypt panel (it pops after a successful
upload), so move the block up to live as a sibling of \`encryptPanel\`
under \`filesharing\` in both en.json and nl.json. Path now matches the
call sites, no component changes needed.
|
Dobby has received the request! Routing to the right specialist now... |
Clicking the "Download your files" link (or the link-text link) inside the preview iframe tried to navigate the iframe itself. The sandbox deliberately omits `allow-top-navigation`, so the navigation was blocked and the iframe blanked out — leaving the modal open with an empty body. Splice `<base target="_blank" rel="noopener">` into the rendered email's `<head>` (or prepend it if the template ever stops having one) before handing the HTML to `srcdoc`. Anchors then open in a new top-level tab, which the existing `allow-popups` / `allow-popups-to-escape-sandbox` flags already permit. No cryptify change needed — the real email never needed `target="_blank"`, only the preview surface does.
Cryptify already returns both MIME alternatives on `/staging/preview/<uuid>` (`html` and `text` on each `RenderedEmail`), but the modal only showed the HTML branch. Add a small tab strip above the body that toggles between the two — the plain-text view renders as a monospace `<pre>` (no iframe, no `<base>` injection needed) so what you see is exactly what a text-only client would receive. Defaults to HTML since that's what most clients pick. Tab state is per-modal-open and resets between recipients via the same active-idx binding (intentional — switching recipients usually means starting fresh).
There was a problem hiding this comment.
Code review
Moves emailPreview i18n block to filesharing.emailPreview where consumers (EmailPreviewModal.svelte, Done.svelte) actually look, adds withBaseTarget() to splice <base target="_blank" rel="noopener"> into the iframe srcdoc so download-link anchors no longer blank the sandboxed iframe, and bumps @e4a/pg-js ^2.0.0→^2.0.1 (commit 7a11cce, not mentioned in the PR body).
Rule compliance
tests-required-on-fixes: this is a bug-fix PR with no Playwright regression test. The third test-plan box (staging verify) is fine for the visual check, but a Playwright test that asserts from/van resolve in the modal and that the rendered iframe srcdoc contains <base target="_blank"> would pin both regressions.
- `FileInput.svelte`: drop duplicate adds in the dropzone. A file already in the list (matched by name + size + lastModified) is silently removed from the dropzone instead of getting a second entry — same behaviour as Gmail's attach UI. - `cryptify` → v0.1.27-9-g63066a1 (picks up the staging preview endpoint that the email-preview modal depends on, plus the `build.rs` Cargo.lock-driven `PG_CORE_VERSION` change). - `postguard` (pg-pkg) → pg-ffi-v0.1.2-9-gcc47b60 (accepts Yivi condiscon in IrmaAuthRequest, which pg-js 2.0 emits for the optional name disjunction). - `docker-compose.yml`: mount `cryptify/build.rs` and `cryptify/Cargo.lock` into the dev container; the bumped cryptify needs both at compile time to set the `X-PostGuard` mail header.
Summary
Three small fixes/improvements on the staging email-preview modal merged in #244:
Test plan