|
|
I reopened it, because it still happen:
Environment
- SOGo: 5.12.10 (Docker)
- Client: Mailer web UI (MessageEditorController.js), Google Chrome
- Affected mailbox with 6 configured identities
Problem
When composing a new email and switching the "From" identity, the previous identity's signature is not removed. The new identity's signature is appended below the old one, resulting in duplicated signatures. The duplicate is persisted because drafts are autosaved after the replacement, so the two signatures get consolidated in the draft. Sending then delivers the mail with both signatures.
Reproduction
- Open compose view with identity A (default). Its signature is inserted normally.
- Switch to identity B from the From selector.
- The signature of A stays in the body and B's signature gets appended below it.
Observations
- Reproducible with 6 identities, each carrying a large (0000063:0000085 KB) HTML signature containing an embedded Base64 image.
- Also reproduced with a smaller signature using an external image URL (not Base64), replacing the original one — same duplicate behavior.
- Not reproduced with regular small plain/HTML signatures.
- No server-side errors; the server logs show normal compose / newDraft.../edit requests.
Root cause analysis (MessageEditorController.js, setFromIdentity)
In setFromIdentity the previous signature is located with a RegExp built from the raw signature HTML:
var currentSignature = new RegExp('(<p>)?...' + currentIdentity.signature)
if (vm.message.editable.text.search(currentSignature) >= 0) {
vm.message.editable.text = vm.message.editable.text.replace(currentSignature, signature);
The HTML is concatenated into the pattern without escaping regex metacharacters. The commented-out line above it shows the original implementation escaped them (e.g. [...].replace(/[-]{}()*+?.,\^$|#\s]/g, '\$&')), which appears to have been lost when 0005695 was merged. HTML signatures commonly contain unescaped characters such as (, ), +, ?, ., {}, | — e.g. rgb(0, 0, 204), font-size:13.3333px, https://... — so the search fails to match (or throws a SyntaxError on unbalanced parentheses) and the old signature is never removed.
Additionally, the error path for "regex too long" does an append instead of a replace:
} catch (error) {
// An error can occur (regex too long) when the signature is too big (using images)
vm.message.editable.text += signature; // append, no replacement
return true;
}
Both paths converge on the same outcome: _.find reports the signature "was handled" (or not found), so the fallback block appends the new signature, duplicating the old one.
Suggested fix
- Escape the signature HTML when building the RegExp (restore the escaping from the commented-out implementation), and
- In the catch path, remove the previous signature (matched by a bounded/loose pattern or a length-limited heuristic) before appending, instead of a plain +=.
Happy to provide a test case (sample identity JSON with signatures that trigger the failure) or verify a patch.
|
related to
child of
duplicate of
