Debounce mouse move handling in QuickView extension

[jasonsanjose]

A lot of activity happens in the QuickView plugin in the handleMouseMove event handler. We should debounce this function to only handle the trailing event.

[marcelgerber]

@jasonsanjose I've just submitted a PR: #6571

[redmunds]

Note that there a special case here: Quick View is delayed on initial detection when something is to be displayed, but there should be no delay if Quick View is already displayed.

How bad is the performance hit? I'm not sure what you mean by "lots of activity". If it's really bad, maybe that special case is not as important.

cc @peterflynn

[njx]

Reviewed. Low pri to @jasonsanjose - feel free to reassign if someone else takes the PR.

[njx]

Oops, shouldn't be assigning new bugs to Jason :) - to @redmunds

[peterflynn]

@redmunds There's a bunch of discussion in @SAplayer's PR #6571 -- not sure if you'd seen that already.

I don't know that @jasonsanjose tried to quantify the performance, but given that it costs something during sensitive operations like scrolling it seems worth trying to minimize anyway. Especially if we want to add more Quick View "providers" later (I could imagine lots of other CSS properties with a Quick View, for example).

Re the special case of immediately showing the popup: that's only necessary on the first mousemove that falls outside the text range of an existing, Quick View popup. So we could still make the general-case mousemove processing much faster/simpler.

[peterflynn]

Closing as fixed -- Randy's fix has landed