A security and an accessibility review of the proofreading hook found
gaps, fixed here.
What leaves the browser:
- A checker gets a name for each composer of its own, not the composer's
id, so it can't reach the message through the other api.composer calls
after proofreading stops.
- Checking pauses while a plugin that can sign or encrypt is turned on but
still starting, and while the policy couldn't be fetched (the built-in
defaults could undo an admin's lock).
- No plugin can hold up turning proofreading off (onBeforeSettingChange).
- Suggestions can't carry zero-width, bidi or line-separator characters;
messages lose bidi overrides; a flood of annotations is cut off early.
- The notices name the plugin as installed, not a label it chose, and say
that text written before signing or encryption was turned on may
already have been checked.
- A checker registered during start-up no longer fails its first check.
Keyboard and screen readers:
- Escape in the issue panel closes the panel, not the message.
- Underlines carry aria-invalid, as the browser's own markers do.
- The focus goes somewhere sensible when a button or an issue goes away,
Tab past the popup's edges goes back to the text, and the shortcuts work
in the popup and the panel.
- Ctrl+' and Ctrl+; follow the character typed, so other layouts keep
their own keys (Ctrl+S on Dvorak), with Ä and Ö on German keyboards.
- The popup is described by its message, sits inside a modal composer,
fits narrow screens, and the panel fits a phone.
Automatic signature insertion was unconditional: any identity with a
signature got it embedded in new mail and appended to replies, forwards
and quick replies. Users who want a signature only in specific contexts
had no way to opt out.
Add two per-account synced settings, both defaulting to off:
- signatureNewMailEnabled: insert the signature in new messages (and
re-opened drafts, which open in compose mode)
- signatureReplyForwardEnabled: append it in replies, forwards and the
quick reply box
With a toggle off the composer neither embeds the signature into the
body, nor appends one at send or draft-save time, nor shows the
read-only preview under the editor - the preview would promise a
signature that never goes out. A signature pasted in by hand is never
stripped (bodyCarriesSignature still short-circuits the append).
Also flip signatureSeparatorEnabled's default from true to false: the
RFC 3676 "-- " delimiter surprised users more than it helped. Only the
default changes - no migration, so users who already set it keep their
choice.
Co-Authored-By: Claude Code <noreply@anthropic.com>
Images in a template arrive as data: URIs (an imported templates file, or a
template saved from a message with a pasted image) and went out as they
were, so Gmail and Outlook did not show them. Inserting a template now
uploads each one like a pasted image and tags it with the cid, so the send
path turns it into a cid: part in multipart/related.
A frame slot `calendar-task-view` draws the task view below Bulwark's
toolbar in place of its list (props: the toolbar's filter, the selected
calendars); `ui.openCalendar({ view })` opens a calendar view and
`ui.openTask(id)` a task in Bulwark's editor.
`ui.openDialog({ anchor: 'trigger' })`: opened within 2 s of a click or
Enter/Space on a host control (a plugin action, a context-menu entry, the
star), the dialog stands as a popover beside that control, still naming
the plugin; without such a trigger it is the centred dialog as before.
A frame slot `side-panel`: a plugin's panel right of the mail list and
reader, opened from a button in the panel rail (Mountain View's, or a slim
rail in the default layout while a plugin offers one). `ui.setSidePanel`
names its button; `ui.openPanel('side-panel')` opens it.
`ui.setSidePanel` takes `rail: false`: the rail draws no button for the
plugin's panel, which then opens only on the plugin's request
(openPanel / togglePanel('side-panel')), e.g. from a top bar action. A
rail left without buttons is not drawn, in the default layout and in
Mountain View's side panel alike.