INP metric: Too many spans with <unknown> target due to disappearing DOM elements

[dariusz-biela]

Problem Statement

We are seeing a large number of INP-related spans where the clicked element is reported as <unknown>. This happens when the user clicks UI elements that immediately disappear from the DOM right after the interaction — most commonly:

• closing buttons (e.g., closing a modal),
• clearing input with an “X” button,
• removing items from lists, cards, etc.

Because these elements are removed, by the time Sentry processes the INP event, e.target is already null, which results in spans showing <unknown> instead of the actual clicked element. This significantly reduces the usefulness and traceability of INP measurements.

Solution Brainstorm

A potential fix is to capture and cache metadata about the clicked element at the moment of the click event — before the element disappears.

Example approach:

1. On click, immediately compute and store the result of htmlTreeAsString(event.target) (or an equivalent helper used for INP).
2. When constructing INP spans, use the cached htmlTreeAsString value instead of trying to read event.target again (which may already be null after DOM removal).

Product Area

Unknown

[linear[bot]]

ENG-5983

[getsantry[bot]]

Assigning to @getsentry/support for routing ⏲️

[getsantry[bot]]

Routing to @getsentry/product-owners-insights for triage ⏲️

[linear[bot]]

JS-1254

[logaretm]

What is the SDK version used here? We shipped a fix in 10.23.0 that should reduce the number of these elements considerably as we observed it on our own end.

[dariusz-biela]

What is the SDK version used here? We shipped a fix in 10.23.0 that should reduce the number of these elements considerably as we observed it on our own end.

• @sentry/react-native: 7.7.0
• @sentry/core: 10.26.0
• @sentry/browser: 10.26.0
• @sentry/react: 10.26.0
• @sentry/webpack-plugin: 4.6.0

In our project: over the last 14 days, approximately 50% of the traces named ui.interaction.click have the span.description value set to <unknown>.

[logaretm]

Perhaps the timing window we limit for the elements cache is a bit aggressive, I will see about increasing it and observing the results.