Smartbar quick-action taps are dropped when the release event is already consumed (Dictate key needs two presses)

[andrius-tr]

Symptom

Every other tap on the Dictate key does nothing at all — no recording starts, no feedback, nothing in the log. Pressing again works. It affects the mic state and the send state equally, so a single dictation costs four taps instead of two.

It reads as a dead button rather than a slow one: the press is simply gone.

Reproduction

1. Open the keyboard with the Dictate action in the Smartbar.
2. Tap the Dictate key repeatedly, at a normal pace.
3. Roughly every second tap does nothing.

Observed on a Pixel 8 Pro (Android 16), v5.3.0 built from source. Not sensitive to press duration or position — the dead taps land well inside the key.

What the log shows

Dead taps emit sendDown followed by sendCancel 12–27 ms later; working taps emit sendDown → sendUp. The pattern alternates cleanly:

50.871 sendDown -214 → 50.930 sendUp      ✅
52.193 sendDown -214 → 52.209 sendCancel  ❌ (16ms)
54.064 sendDown -214 → 54.136 sendUp      ✅
56.285 sendDown -214 → 56.303 sendCancel  ❌ (18ms)

12–27 ms is far too fast to be a finger lifting, and QuickActionButton never leaves composition (I instrumented the DisposableEffect(action, isEnabled) — it does not fire for -214 around these taps). So the cancellation comes from the gesture itself: waitForUpOrCancellation() returns null.

Instrumenting that return shows the event responsible:

cancel@MAIN type=Release n=1 id=7 pressed=false consumed=true pos=Offset(6.0, 14.8)

The release — the finger genuinely lifting on the key — arrives already consumed.

Root cause

changedToUp() is defined as !isConsumed && previousPressed && !pressed. A consumed release therefore isn't recognised as an "up" at all, so waitForUpOrCancellation() falls through to its cancellation path and a completed tap is discarded.

Both gesture branches in QuickActionButton are affected — the long-press-aware one the Dictate key takes when idle, and the plain else branch it takes in its send state — which is why the mic and send buttons fail identically.

What I could not determine: what consumes the release. I fixed it at the button, but you may prefer to fix it at the consumer, which is why this is an issue rather than a PR.

Fix I'm running

A drop-in replacement for waitForUpOrCancellation() that

• detects the lift with changedToUpIgnoreConsumed(), so a consumed release still counts as a tap, and
• cancels only when a change is consumed while still pressed — the genuine "another handler took the drag" case.

It also drops the isOutOfBounds cancellation, so a thumb that rolls a few pixels doesn't cost a tap. Used by both branches.

Verified on device: 6 presses → 6 sendDown, 6 sendUp, 0 sendCancel, where the same test previously alternated.

Happy to open a PR if the approach looks right to you — and equally happy to test a fix at the consumer end instead, since that may be the more correct layer.

[DevEmperor]

Confirmed, and your diagnosis is better than the one I arrived at independently — thank you for the depth here.

I hit the same thing from the user side in #261 ("the mic needs two taps to start and two to stop") and measured the same signature: sendDown, then the gesture ending 15 ms later with the finger still down and no dispose in between. What I could not explain was why a completed press was arriving as a cancellation. changedToUp() being !isConsumed && previousPressed && !pressed, and the release arriving already consumed, is exactly the missing piece.

What has shipped

The Dictate key is fixed on main as of 99b6f28 — but by a different route than yours, so it is worth being precise about what that does and does not cover.

Rather than repairing the gesture, the mic press now comes from the window's own touch stream: ImeRootView.dispatchTouchEvent reports the press, and everything after it — the delay separating a tap from a hold, sliding, latching, releasing — is decided outside the Compose coroutine (DictateHoldTouch). The hold path already worked that way for push-to-talk (#235), where the same cancellation was losing whole recordings; #261 extended it to the plain tap. Verified on device: 10 taps → 10 presses delivered, 0 cancelled, and 5 of 5 recordings sent on the first tap where the same test previously needed a second one.

That covers the mic and the send state — the two states of the Dictate key, which is what your reproduction exercises.

What is not covered

Every other quick action still takes the old path. handleUpOrCancel(waitForUpOrCancellation(), …) is unchanged for undo, clipboard, emoji, settings and the rest, so if a consumed release can reach them, they drop taps exactly as the mic did. Nothing about the mechanism you describe is specific to the Dictate key.

I have no evidence either way yet: a control run on the undo key with tooltips enabled showed no dropped taps here, but that was an emulator, and your Pixel 8 Pro is where the pattern is clean and repeatable. So the question back to you: on current main, do you still lose taps on any quick action other than Dictate? If you do, your fix is the right layer and I would take the PR — the window-level route makes sense for the mic (it also has to survive holds, slides and latching) but it is far too much machinery for an ordinary button.

There is also a residual case on our side worth naming: if the window never saw the press land, the Dictate key falls back to the same waitForUpOrCancellation() path and would fail the same way.

One question about the fix itself

changedToUpIgnoreConsumed() plus "cancel only when a change is consumed while still pressed" looks right to me — that is the genuine "another handler took the drag" case and nothing else.

The part I would push back on is dropping the isOutOfBounds cancellation. Sliding off a key to abort it is an expectation people bring to every button, and losing it to fix a few pixels of thumb roll is a trade I would rather not make silently. Could the same effect be had by keeping the bounds check with a slop margin, so a small roll survives but a deliberate slide-away still cancels?

And the open question is still open: what consumes the release. Both fixes work without knowing, which is a little unsatisfying — if you ever catch the consumer, I would like to know.

Leaving this open for the wider quick-action question rather than closing it on the mic alone.

[andrius-tr]

Thanks — and glad the changedToUp() detail was the missing piece; that one took a while to see.

Your question: other quick actions on current main

Not yet empirically, and I want to be precise about that rather than imply otherwise. My fork is based on v5.3.0, so I haven't run your main. What I can say is what 99b6f286 itself shows:

val armed = when {
    dictateIdle && isPushToTalkActive -> DictateHoldTouch.arm(...)
    isDictate                         -> DictateHoldTouch.armTap(...)
    else -> false
}
if (!armed) {
    handleUpOrCancel(waitForUpOrCancellation(), press, interactionSource, action, context)
}

else -> false, so undo, clipboard, emoji, settings and the rest still reach waitForUpOrCancellation() unchanged. Nothing in the mechanism is mic-specific, so I'd expect them to drop taps under the same conditions — but expecting isn't measuring, and I'll get you a real number on your main before claiming it.

The argument I'd actually make for the shared-layer fix is the residual case you named yourself. That if (!armed) branch is also the mic's fallback when the window never saw the press land — so on current main the Dictate key can still fail by exactly the old route. Repairing the primitive underneath covers your fallback and every other action, without either of us needing to know which recomposition provokes it.

I don't think that makes DictateHoldTouch redundant. The mic genuinely needs the window's stream — it has to survive holds, slides and latching, and no gesture-level fix gives you that. The two changes seem complementary: yours makes the mic's intended path robust, mine makes its fallback path and every ordinary button correct.

On isOutOfBounds — you're right, and I've changed it

Dropping it outright was the wrong trade and I've put it back with a slop margin, as you suggested. The margin is ViewConfiguration.touchSlop — the platform's own threshold for "this movement is deliberate" — and the check runs only while the pointer is still pressed, so it can never turn a release near the edge back into a cancellation, which is the failure the whole helper exists to fix.

Verified on device against the undo key, which shares the path:

• tap → fires on the first press ("hello" → "h")
• press and slide away → correctly cancelled, text unchanged

Your open question: what consumes the release

Still don't know, and I'd rather say so than guess. Both fixes work around it without explaining it, which I agree is unsatisfying. If I catch the consumer I'll post it here.

Happy to open the PR whenever you want it — I'd suggest after I've measured your main, so the change arrives with evidence rather than an argument.