[zzfn]

#57 holds hover styling still for 100 ms after a wheel event while the pointer stays put. It did this by emptying the window's hit test (mouse_hit_test). The cursor is resolved from that same hit test, so every frozen frame set the arrow over text, and the next wheel event restored the text cursor: the cursor flickered while scrolling.

Change

• The hit test is no longer emptied during the freeze; it stays the geometry under the pointer. hover_freeze::begin_draw is removed and hover_freeze::hit_test always returns the real hit test.
• The freeze moves into hover itself: HitboxId::is_hovered (and hovered_now, its retained-view twin) returns false while hover_freeze::frozen is true.
• Cursor resolution uses is_hovered_ignoring_last_input, which doesn't check the freeze, so the cursor follows the geometry under the pointer. reset_cursor_style is unchanged.
• A list's foretold hit test still stays empty while frozen (fast/layers/lists.rs), so rows aren't rendered again for hover.

Tests

• New: the_cursor_follows_the_text_under_a_still_pointer_while_hover_is_frozen. The text cursor stays over text throughout the freeze, and the arrow comes back once the pointer leaves the text.
• Updated: hover_held_still_while_the_wheel_scrolls_renders_no_row_for_it now asserts that the hit test is non-empty while no hitbox reports hovered.
• Test helpers: TestPlatform::active_cursor_style and Window::set_owns_pointer (#[cfg(test)]).

[huacnlee]

Moving the freeze from the hit test into hover is the right direction: the cursor goes through is_hovered_ignoring_last_input, so it follows the geometry. A few things need to change before this can merge.

1. A click within 100 ms of a wheel event, without moving the pointer, is dropped

While frozen, HitboxId::is_hovered now returns false for every hitbox. frozen() only checks the pointer position, and a mouse down at the same position doesn't change it. The div mouse down/up/click listeners all require hitbox.is_hovered(window) (elements/div.rs:135, :152, :168, …), so that click never reaches its handler.

Before this PR clicks still worked, because dispatch_mouse_event recomputes mouse_hit_test before dispatching (window.rs:6006). Two possible fixes:

• end the freeze on any non-wheel pointer input (mouse down/up), or
• apply the freeze only to hover styling while drawing, not to event dispatch.

Please add a test: wheel, then mouse down/up at the same position, and assert that the click handler runs.

2. script/check-upstream fails (2 violations)

• platform/test/platform.rs:428: TestPlatform::active_cursor_style is a new method in an upstream file.
• window.rs:3018: Window::set_owns_pointer (plus its doc comment) is a new method in an upstream file. window.rs is also over the budget (+112 > 99, −37 > 36).

Methods on upstream types belong in an impl block under fast/ (e.g. a #[cfg(test)] impl in fast/tests/ or the topic module). The upstream side should only bump visibility where needed (active_cursor, active, hovered → pub(crate)).

3. Nit: the freeze check is duplicated

HitboxId::is_hovered (window.rs) and hovered_now (fast/retained.rs) now both repeat last_input_was_keyboard() || hover_freeze::frozen(window). A single fast/ helper called from both places would keep the window.rs hook to one call.

[zzfn]

Thanks, addressed in bdfeda0:

1. Hover is now held only while drawing, so dispatch sees the geometry and the click lands. Added a_click_under_a_still_pointer_right_after_the_wheel_reaches_its_handler (fails on the previous commit).
2. Test helpers moved to fast/tests/support.rs; upstream only gets the pub(crate) bumps. hover_freeze::hit_test had become upstream's own line, so I restored it, which keeps window.rs at +99/−36.
3. One helper, hover_freeze::hides_hover, used by both is_hovered and hovered_now.

The two wheel tests no longer assert !is_hovered between frames, since outside drawing it now reports the geometry. Held hover styling is still covered by no row being rendered for its hover.