fix(muya): keep the link popover open when moving between links (#5313) - #5324

Fixes #5313.

Root cause

linkMouseEvents.ts drives the popover with one event: hovering a link emits muya-link-tools with a reference, and leaving one emits it with reference: null. LinkTools.listen() turns the second form into a delayed hide:

else {
    if (this._hideTimer)
        clearTimeout(this._hideTimer);
    this._hideTimer = setTimeout(() => { this.hide(); }, 500);
}

The show branch never touched _hideTimer. Because moving the pointer from one element to another fires mouseout on the old one before mouseover on the new one, the sequence for two adjacent links is:

1. mouseout on link A → { reference: null } → arms a 500ms hide
2. mouseover on link B → { reference: B } → popover shown for B, stale timer still armed
3. 500ms later → hide() → the popover closes while the pointer is on link B

The delay exists so the pointer can travel from the link to the popover without it closing. It was only ever cancelled by the mouseover handler on the popover container itself, so any path that re-enters a link first left the timer running.

That matches the report exactly: it is worst with consecutive anchor lines, because the pointer then crosses links almost continuously, so a stale hide is nearly always pending. The popover flickers and vanishes before it can be clicked, leaving Ctrl+Click as the only way to follow a link.

The fix

Cancel the pending hide when a reference arrives:

if (this._hideTimer) {
    clearTimeout(this._hideTimer);
    this._hideTimer = null;
}

Nine lines including the comment, in the one branch that was missing it. The delay itself is unchanged, so leaving a link and going nowhere still hides after the usual 500ms.

Verification

Two tests added to the existing linkTools.spec.ts, using its bootLinkTools() harness (real EventCenter, real LinkTools) with fake timers, asserting on BaseFloat's public status flag:

• keeps the popover open when the pointer moves straight to another link — replays the exact three-step sequence above and advances 1000ms.
• still hides when the pointer leaves a link and goes nowhere — guards the other direction, so the fix cannot degrade into "never hides".

Reverting just the index.ts change makes the first test fail and leaves the second passing:

- Expected   + Received

- true
+ false

 ❯ src/ui/linkTools/__tests__/linkTools.spec.ts:222:34
    expect(tools.status).toBe(true);

 Test Files  1 failed (1)
      Tests  1 failed | 7 passed (8)

With the fix, the full muya suite is green:

 Test Files  222 passed (222)
      Tests  1518 passed (1518)

eslint src/ui/linkTools and tsc --noEmit are both clean in packages/muya.

Notes

I could not reproduce on Windows 11 as reported — I verified on macOS. The mechanism is platform-independent (DOM event ordering plus a timer), and the reporter's "densely stacked anchors" detail is what makes a stale hide almost always pending, so I'm confident it is the same bug. If you would like it confirmed on Windows before merging, I'm happy to wait for someone with that setup.

I left the mouseOverHandler on the popover container alone; it clears the timer without nulling it, which is harmless since every read is guarded.