Version:
- listmonk: v6.2.0 (Docker)
- OS: server Amazon Linux 2023 / client Chrome and Edge on Windows
Description of the bug and steps to reproduce:
In the campaign test-send box, the first click on the send button is silently swallowed whenever the typed address has not been committed as a chip yet. No request is made at all, so it looks exactly like a backend failure ("test sends silently never arrive") — we lost several debugging sessions to it before catching the mechanism.
Steps:
- Open a campaign, scroll to "Send a test message".
- Type a full email address into the test-email
b-taginput and do not press Enter (so it stays as pending text, not a chip).
- Click the send button once.
- Nothing happens: no network request (devtools Network tab stays empty), no toast, no error. A second click works.
Mechanism, confirmed by deliberate reproduction:
- clicking the button blurs the taginput;
- Buefy's
customOnBlur calls addTag(), which pushes the chip synchronously;
- the field grows a row taller, so the button moves down between
mousedown and mouseup;
- the browser therefore never dispatches a
click, and the handler never runs.
The second click works because the chip already exists and nothing reflows — which makes the button look like it "acted as Enter the first time". Since the request is never made, there is nothing to find server-side; every log is clean.
There is also a second-order variant: sendTest() reads only committed chips (form.testEmails), so in situations where no reflow happens the click lands but a typed-but-uncommitted address is silently dropped from the payload.
Fix that worked for us (as a local patch — not PRing per the CONTRIBUTING freeze on admin-frontend changes until v7): @mousedown.native.prevent on the send button, so the taginput never blurs before the click lands, plus committing any pending input via the taginput ref inside sendTest(). Either half alone is insufficient. The general trap — a control that synchronously reflows its own container on blur can eat its own click — may be worth keeping in mind for the v7 UI as well.
Screenshots:
Not applicable — the defining symptom is the absence of any request or feedback on the first click.
Version:
Description of the bug and steps to reproduce:
In the campaign test-send box, the first click on the send button is silently swallowed whenever the typed address has not been committed as a chip yet. No request is made at all, so it looks exactly like a backend failure ("test sends silently never arrive") — we lost several debugging sessions to it before catching the mechanism.
Steps:
b-taginputand do not press Enter (so it stays as pending text, not a chip).Mechanism, confirmed by deliberate reproduction:
customOnBlurcallsaddTag(), which pushes the chip synchronously;mousedownandmouseup;click, and the handler never runs.The second click works because the chip already exists and nothing reflows — which makes the button look like it "acted as Enter the first time". Since the request is never made, there is nothing to find server-side; every log is clean.
There is also a second-order variant:
sendTest()reads only committed chips (form.testEmails), so in situations where no reflow happens the click lands but a typed-but-uncommitted address is silently dropped from the payload.Fix that worked for us (as a local patch — not PRing per the CONTRIBUTING freeze on admin-frontend changes until v7):
@mousedown.native.preventon the send button, so the taginput never blurs before the click lands, plus committing any pending input via the taginput ref insidesendTest(). Either half alone is insufficient. The general trap — a control that synchronously reflows its own container on blur can eat its own click — may be worth keeping in mind for the v7 UI as well.Screenshots:
Not applicable — the defining symptom is the absence of any request or feedback on the first click.