TOOLTIP_DISPLAY_DELAY is not respected for continuous mouse movement within a token

[chrismwendt]

• Visit https://github.com/gorilla/mux/blob/master/mux.go
• Move your mouse continuously across a token
• Notice the tooltip immediately appears, but it should stay hidden until you stop moving the mouse for TOOLTIP_DISPLAY_DELAY

I have a suspicion this regression was introduced in f6547cc (specifically the hunk below f6547cc?w=1#diff-8a128e9e8a5a8bb9767f5f5392391217R230). It looks like that commit switched from considering mouse movement by pixels to tokens.

[ijsnow]

I don’t think this is a regression.

What do you mean by considering mouse movement by pixels to tokens?

It currently(and always has) gotten the events from the tokens dom element itself. This means that the event is triggered from the instant the mouse first goes over the token and that point in time is where the delay starts counting.

When we fully switch over to event-positions and are using pixels rather than the event target we can easily start the delay when it stops moving. It’s still possible now but would probably require some tricky logic.

[chrismwendt]

Oh, it might not be a regression in the browser extension. I was thinking of https://github.com/sourcegraph/sourcegraph/issues/11457 (in the Sourcegraph web app)

Could one of the solutions in https://github.com/sourcegraph/sourcegraph/pull/11467 or https://github.com/sourcegraph/sourcegraph/pull/11768 be applied here?

[felixfbecker]

Could one of the solutions in sourcegraph/sourcegraph#11467 or sourcegraph/sourcegraph#11768 be applied here?

That code is in codeintellify: https://sourcegraph.sgdev.org/github.com/sourcegraph/codeintellify@e6a1f16c94058c12cc58a8085d623ee2171250f6/-/blob/src/hoverifier.ts#L308-329

[chrismwendt]

@felixfbecker Any idea why this behavior is happening? I'm noticing this on the web app too

[felixfbecker]

No, but I would say it's not really a big problem, is it? It is probably not worth investigating if this all changes with event-positions

[nnchang]

I would agree it's not a big problem (especially if it's already changing as part of a bigger change), but the UX of just moving the cursor normally and having many tooltips momentarily fade in and out is pretty obnoxious and distracting. If this library is entirely about adding tooltips to code, I'd argue that producing these tooltips in an overly-noisy manner is very much a bug.