apm-agent-rum-js: React: User Interaction only returns "Click - div"

This issue is possibly related to the intended fix from PR elastic/apm-agent-rum-js#951, however applying the changes there do not resolve the below issue for me.

Whenever a target is clicked, the USER_INTERACTION event is fired. As an example button:

<button name="applyFiltersBtn" class="ui icon primary left labeled button">
  <i aria-hidden="true" class="check icon"></i>
  Apply
</button>

This then fires the following log:

[Elastic APM] startTransaction(86115b370489ca7c, Click - div, user-interaction)

As you can see, the name of this transaction is titled Click - div, even though the (what looks like) intended behaviour of performance-monitoring.js:189 is to grab the name attribute from the element, in this case applyFiltersBtn. I’d expect this transaction to be named Click - button["applyFiltersBtn"] and for this to be recorded in the APM under a “user-interaction”, whilst capturing network traffic to include spans such as API requests, etc.

When doing some debugging, I logged out what was being passed to shouldInstrumentEvent (or from elastic/apm-agent-rum-js#951, I have this applied change, along with the other changes from the PR). When logging the target variable from the shouldInstrumentEvent function and also logging the target from the getEventTargetSub, in all cases both parts of the aforementioned give back one of the following:

<div id="root">
Window
<react><react/>.

It never gives back the actual target of (in the example above) a Button. Is this intentional, if so, how would one implement a transaction to follow up on user interactions with buttons and log them correctly in APM, with React?

About this issue

Original URL
State: closed
Created 3 years ago
Reactions: 2
Comments: 22 (9 by maintainers)

Most upvoted comments

We can fix this today by using the technique described here - https://github.com/elastic/apm-agent-rum-js/pull/951/files#r588056071. the resulting value of transaction would be Click - button["applyFiltersBtn"]

I would add this check to the PR and it should be good to go.

vigneshshanmugam on Mar 5, 2021

@reecebenson Thanks for the extensive test. I did a quick look around the new React 17 event system. It seems like React is registering two click events on the application root where the react app is mounted One with useCapture flag set to true and other with false.

As a result, I can see your test producing redefining transactions with no changes and also document.activeElement also not having the correct focus.

I am still doing some testing to figure out what would be the best solution here.

@clyfish Not sure why you closed the PR. Using window.onclick is easier, but it does not guarantee that

our listeners always fires before everyone elses
We have to also account for events that have been explicity called with e.stopPropagation or e.preventDefault.

So if we can fix it using eventtarget, it would be a better solution.

vigneshshanmugam on Mar 17, 2021

@reecebenson I’ve tested without your workaround, and it works on Chrome 89. What browser did you test on?

If there is an http-request transaction after the user-interaction transaction within 100ms, The user-interaction will not be discarded, because the user-interaction transaction has no spans itself and the http-request transaction has.

https://github.com/elastic/apm-agent-rum-js/blob/6461364642e8879c613d7ce7e187e52bfb32ba54/packages/rum-core/src/performance-monitoring/performance-monitoring.js#L211

@clyfish I’m testing using Firefox 86, but still seeing <div id="root"> whilst testing without my workaround. We’re using React 17.0.1, that I know has some breaking changes from v17 (namely the changes to event delegation). I haven’t retested using Chrome (don’t have it installed, unfortunately) but will try and get to that today.

Regarding the network activity, in my use case 100ms isn’t enough buffer time to track network activity, as I have state changes to apply before firing something to the API. There doesn’t look like there is a way to override this value either. I don’t want to propose an increase in this value as it’s probably a single use-case, but an override to this value would be beneficial for some. Is that something we could introduce here, possibly a new issue for tracking?

also, another question … after collecting all user interactions as transactions how I can see them in time order kinda like breadcrumbs, to understand exactly what the user did in sequence?

@StefanoSega Please create a new issue as your question is irrelevant to this issue. It makes these issues difficult to follow if conversation starts becoming off-topic.

reecebenson on Mar 8, 2021

We can fix this today by using the technique described here - https://github.com/elastic/apm-agent-rum-js/pull/951/files#r588056071. the resulting value of transaction would be Click - button["applyFiltersBtn"]

Sounds good, I’ll give that a test with @clyfish’s latest updates to that PR and report back here. Cheers for the update!

reecebenson on Mar 5, 2021