Perhaps not abort them, but keep them in the client's cache and not show them?

@mobrovac we don't show them, that's not a problem but the request still happens so probably a high percentage of hits to the endpoint are not necessary (other than keeping the cache full... which might be a good thing!).

We talked about this in grooming today. The only plus to aborting requests would be the client would not download the summary unnecessarily.

We're a bit concerned about page previews being invoked while the mouse is moving and text is being selected.
@Jhernandez @phuedx do you have any background on this? Should we also be listening for mouseout events to prevent these requests?

Something we should talk about in dev time?

There should be a 150ms delay before we fire AJAX query https://github.com/wikimedia/mediawiki-extensions-Popups/blob/master/src/actions.js#L16

For more info please read https://phabricator.wikimedia.org/T70861#3129780

it's difficult to measure 150ms. To verify if this logic works properly, we can increase the timeout from 150ms to like 2s and verify the current fetch dealy start on the local instance.

The age is never reset for cached page previews (T184534). For many articles, this means that most clients will always issue a network request for a given preview regardless of whether they've previously requested the preview or not.

TL;DR;

ABANDON_END_DELAY has to be lower than FETCH_DELAY_START, otherwise, we trigger AJAX event after every LINK_DWELL event.

Lets check if FETCH_DELAY_START works properly

Let's check if I set the FETCH_DELAY_START to 2500ms everything still works correctly as my assumption is that the AJAX event is fired without delay:

The first couple LINK_DWELL events were just moving a mouse pointer over lin - it properly calls LINK_DWELL, then ABANDON_START, and ABANDON_END.
As you see, the selected FETCH_START happens only after 2.5s

It looks like it works, let's analyze the flow when `FETCH_DELAY_START = 150ms

The strange thing happens when I set the FETCH_DELAY_START is set to 150ms, the FETCH_START event should should happen after 0.15s

The FETCH_START event is called after 0.07s (70ms), 0.09s (90ms), 0.1s (100ms),. 0.14s (140ms), but the previous event is ABANDON_START.

The ABANDON_START doesn't "hold" the request, it waits 300ms (https://github.com/wikimedia/mediawiki-extensions-Popups/blob/master/src/actions.js#L30), and if the mouse pointer didn't re-enter the link it resets the state.
But because the ABANDON_END_DELAY is longer than FETCH_DELAY_START we will always fire an event.
Looks close to the second screenshot,

• first set of events`ABANDON_START` happened 70ms after LINK_DWELL, and then FETCH_START happened 70ms after ABANDON_START. 70+80 => 150ms
• lets check something in the middle - ABANDON_START happened 50ms after LINK_DWELL, then FETCH_START started 100ms after ABANDON_START => 50+100 => 150ms

I think we know whats going on, lets set ABANDON_END_DELAY to 150ms, and FETCH_DELAY_START to 150ms and let's see what happens

Last try, lets set ABANDON_END_DELAY to 150ms, and FETCH_DELAY_START to 300ms and let's see what happens

Possible solutions:

• code that triggers (timed action) FETCH_START first should check current state, and not fire event when state is in ABANDON_START, instead it should wait
• ABANDON_END should cancel the timed action of calling AJAX, and we have to introduce ABANDON_ABORT that triggers the FETCH_START event once again
• leave code as it is, just make ABANDON_END_DELAY < FETCH_START_DELAY / 2
• if preview is not present, fire ABANDON_END immediately

Another possible solution:

• Whenever a new link interaction is created, if there's an ongoing request, then cancel it.

We fire the AJAX call after each time a user dwells on the link.

To clarify this do you mean 150ms after a user dwells on the link? I'm guessing the 150ms is so minimal that it's essentially 100% the time but I want to make sure I completely understand.

Thanks for the clear answers @pmiazga
So it sounds like your proposal is that ABANDON_START should abort any pending API requests? Is that correct?

In T193055#4300084, @Jdlrobson wrote:

So it sounds like your proposal is that ABANDON_START should abort any pending API requests? Is that correct?

I'd recommend LINK_DWELL. There's already logic to determine if there's a new interaction being started (when we would want to abort in-flight requests) for that action.

In T193055#4300084, @Jdlrobson wrote:

We fire the AJAX call after each time a user dwells on the link.

To clarify this do you mean 150ms after a user dwells on the link? I'm guessing the 150ms is so minimal that it's essentially 100% the time but I want to make sure I completely understand.

yes, the delay is 150ms after the LINK_DWELL - it doesn't matter if any other state is called in the meantime, code always wait 150ms and fires AJAX request.
I did some testing, and when I move the mouse quickly (like I want to move to a link in the middle of the article) usually I dwell on couple links on the way, the time between LINK_DWELL and ABANDON_START for a link that was on the path of mouse pointer is usually less than 100ms.

Thanks for the clear answers @pmiazga
So it sounds like your proposal is that ABANDON_START should abort any pending API requests? Is that correct?

I think that the best approach is to:

• on new LINK_DWELL reset the state
• on FETCH_START check if isDwelling = true before firing the request. This can be tricky, because if user dwells on the same link before ABANDON_END_DEALY we do not fire LINK_DWELL again.

Thanks for looking into this. Next step is to estimate T197700