fix: stop scroll ticks cancelling the floating toolbar's pending show

[matanrotman]

Problem

The desktop floating toolbar debounces two independent triggers onto a single key ('show the toolbar'):

• selection changes — 200ms
• scroll offset changes — Duration.zero

Debounce.debounce() is keyed by name, so the later call replaces the earlier one. Whichever fired last won; the other was silently dropped.

These two interleave during any drag that auto-scrolls — selecting text and pulling past the viewport edge, which is precisely when the toolbar has to track a selection extent that doesn't exist on screen until the scroll happens. A scroll tick lands on the shared key, cancels the pending (and more authoritative) selection-driven show, and the toolbar never appears.

There is a second issue in the same path. Auto-scroll calls _onScrollPositionChanged from its own ticker, in the same call stack as the offset change — before the layout pass that repositions the scrolled content has run. _showToolbar therefore measures geometry left over from the previous frame.

Fix

• Give each trigger its own debounce key (_selectionDebounceKey, _scrollDebounceKey) so they can no longer evict one another. _showAfterDelay takes the key as a parameter; _clear() and dispose() cancel both.
• Defer the scroll-triggered show to addPostFrameCallback with a mounted guard, so the toolbar reads geometry only after the frame has settled.

No public API change — both keys are private to _FloatingToolbarState. The mobile toolbar has a single trigger and is deliberately untouched.

Testing

This has been running in a downstream fork (AppFlowy) for several sessions, where the floating toolbar behaves correctly — including after selections that require scrolling, which is the case that originally surfaced the bug.

I should be upfront that I could not get a widget test to fail against the unfixed code. A single jumpTo() + pumpAndSettle() doesn't recreate what a real drag does — a continuous stream of scroll ticks that never fully settles — and that stream is exactly what makes the two debounce calls race. So the diagnosis here rests on reading the code path rather than on a reproducing test. Happy to add one if you can point me at a pattern that drives auto-scroll faithfully.

🤖 Generated with Claude Code

[CLAassistant]

All committers have signed the CLA.