Motivation

Click target inaccuracy

When the click starts (mouse/pointer down) on an element and ends (mouse/pointer up) on another element, the click event target is set to the BODY element by the browser. This is problematic, because we report clicks occuring on the BODY even if the user uses a whole other element. This impacts the RUM click action target name (@action.target.name), as well as the experimental heatmaps CSS selector generation.

Using the pointerdown event target instead improves the situation: the element used to compute the action target name and CSS selector is the element the user intended to click.

Heatmap CSS selector improvement

Some application add a temporary class name when an element is being clicked (similarly to the :active CSS pseudo-class) or focused. Those temporary class names blocks us from finding again the element when rendering the Heatmap again.

Generating the CSS selector before the application UI reacts to it should improve the situation a bit (pointerdown is the first event triggered when a click occurs).

Frustration signal follow-up

This change is also a first step in fixing one of the most common dead click false positive cases: currently, we are only watching for page activity during or following a click event. But in some cases the application updates the UI earlier (ex: on mousedown, focus...). Those kind of clicks we are incorrectly considered a click as "dead".

In a future follow-up, we'll fix this by watching page activity during or following the pointerdown event as well, to avoid marking those clicks as "dead".

Changes

Beside a bit of refactoring, the main change was to update the listenActionEvents to call a callback on pointerdown. This callback can return a onClick closure that will be called during the next click event. This allows to build the target-related properties earlier and still build the Click during the click event.

Testing

• Local
• Staging
• Unit
• End to end

Notes

This PR does not fix the issue in the recorder part: clicks event will still be reported on the body element when the element target changes between mousedown and mouseup. This should not matter too much, as the click position is also collected.

To keep backward compatibility, the event send as context in the beforeSend callback is still the click event.

I have gone over the contributing documentation.