@Niedzielski and @pmiazga you recently touched this code as part of T197700.
Olga has suggested this is normal priority, but addressing this problem feels like a risky change that may impact aborted AJAX requests amongst other things. What do your guts say? Is this an oversight or is it going to be tricky to untangle?

@Jdlrobson, I think this might be a little tricky.

The previous implementation never canceled an outstanding request so if a link was _ever_ hovered over, as long as the cursor was back over the link when the request and timers _completed_, a preview would be shown. Now, as soon as the cursor leaves the link, the request is aborted and any timers canceled.

I'm guessing there's a timing issue between issuing a new request and aborting the old. In the code I see:

if (!isNewInteraction()) return $.Deferred().resolve().promise()

If this is the issue, conceptually the change may be as simple as modifying isNewInteraction() to check fetch response / timer status but I expect it will be trickier in practice to fix. I would not be surprised if this was a preexisting issue but is now greatly exacerbated :[

@ovasileva It would be worthwhile organising a spike/feasibility analysis before addressing this problem as it's risky, so we can expect this task to take up at least 2 sprints. Unsure if the priority of this task is such that we want to address it soon, given we are trying to pause work with page previews for the time being.

The issue is the space between the lines - that is not technically the link. I think fixing this could be risky as it would require changing the sensitivity of page previews by changing what we class as a dwell which could impact usability by displaying previews on accidental hovers.

@ovasileva I would recommend declining, particularly given the age of this ticket.