Soft navigations triggered by mouse up not detected

[ErikWitt]

Hi there!

We came across this page where we tried out the Chrome origin trial https://www.tom-tailor.de/

We tracked the new soft navigations in our RUM and were surprised to see only about 50% of the soft navigations that next.js reports via performance marks (which we track as well).

Digging into this, we found that their product tiles on listing pages (e.g. https://www.tom-tailor.de/sale) does not trigger on "click" but on "mouse up" instead. To be more specific

• Clicking on the product title, a click listener on the inner anchor tag triggers a soft navigation. This one IS captured by the heuristics.
• Clicking on the product image, a mouse up listener on the outer anchor tag triggers a soft navigation. This one IS NOT captured by the heuristics.

As pointed out to me by @tunetheweb, this behaviour is by designed according to https://github.com/WICG/soft-navigations#heuristics

I would argue, events like mouse up should also be included.

We see this pattern regularly on e-commerce pages. Their JS code listens to mouse down and mouse up events to ensure the cursor has not moved between up and down and only then triggers the navigation. The reason for this is that they use slider elements on the page an need to distinguish clicks from "swipe-like" interactions with the mouse.

[tunetheweb]

From the heuristics:

That operation results in an event handler firing (a “click”, “navigate”, "keydown", "keyup" , or "keypress" event).

This request is to include "mouse up" in there, but from #13 (comment) it seems like "mouse down" is also wanted. Since "key up" and "key down" are included does it make sense to include these?

Additionally, should we include "pointer up"/"pointer down"?

[mmocny]

I think that one of the reasons this was not immediately addressed is similar to what makes Event Timing Interactions difficult -- a pointerdown may or may not turn into a scroll (or other complex e.g. IME use cases) -- and so you end up waiting an arbitrary amount of time for future events to see what actually happens.

Right now, Soft-nav-heuristics make decisions synchronously (at the moment of event dispatch), and each new interaction may reset / override certain global/singleton things (i.e. sof-tnav affected paint area).

Supporting pointerdown (etc) would mean supporting speculatively starting soft-nav tracking, but then waiting to see if the event actually does convert into an interaction, failing gracefully, and not overriding any real navigations which are in progress.

(Concretely: Clicking a link and then quickly touch swiping to scroll while its still loading should work, but I think wouldn't work, if we just added pointerdown to the list over events that could trigger soft nav.)

There has been some work to support "overlapping interactions" and maybe this enables adding these as well.

---

2cents: In a perfect world Soft-navs just builds upon the "Interactions" concept already established by Event Timing -- but we'd need to evolve that to support observing "potential interaction started" and then "aborted" or "finalized".

[mxmul]

We've opted into the Chrome origin trial at Airbnb, and noticed a similar issue. Dragging the map on a page like https://www.airbnb.com/s/paris/homes doesn't result in a soft-navigation, even though it triggers a search (which results in DOM changes and a history change).

I suppose this is because the action is triggered by a "drag" or "dragend" event rather than a click - should these events be considered by the heuristic?

[liang3404814]

We've opted into the Chrome origin trial at Airbnb, and noticed a similar issue. Dragging the map on a page like https://www.airbnb.com/s/paris/homes doesn't result in a soft-navigation, even though it triggers a search (which results in DOM changes and a history change).

I suppose this is because the action is triggered by a "drag" or "dragend" event rather than a click - should these events be considered by the heuristic?

Adding to this, I notice that if you clicked on the plus/minus icons on the top right, then the search triggered does result in a soft-navigation. Searches triggered by dragging/double-clicking/scroll wheel actions on the map also aren't considered as soft-navigations.

[mmocny]

This is all excellent feedback!

I think, however, that at the moment we are mostly looking to improve within the narrow scope of click interactions and try to ensure that the soft-nav-entry and paint entries that follow it are as accurate and reflective as possible.

We can work on widening the scope of coverage after that.