fix(browser): Keep the first element name captured for an interaction - #24272
Open
logaretm wants to merge 1 commit into
Open
fix(browser): Keep the first element name captured for an interaction#24272logaretm wants to merge 1 commit into
logaretm wants to merge 1 commit into
Conversation
Contributor
size-limit report 📦
|
logaretm
force-pushed
the
awad/inp-element-name-first-write
branch
from
September 9, 2026 22:59
e5cf7e0 to
f46520d
Compare
logaretm
changed the base branch from
awad/js-1019-soft-nav-web-vitals-spans
to
awad/bfcache-web-vitals
September 9, 2026 22:59
logaretm
force-pushed
the
awad/inp-element-name-first-write
branch
from
September 9, 2026 23:18
f46520d to
f1b239d
Compare
logaretm
added this pull request to stack #24274
September 9, 2026 23:18
The INP element-name cache is keyed by the rounded event timestamp and every event of one interaction shares that timestamp, so the last write won. When a click handler swaps out the element under the cursor, the browser then fires `pointerover`/`mouseover` for the new element carrying that same timestamp, and those overwrote the cached name. An INP span for a click that navigated away was named after the post-mutation DOM rather than the element that was clicked. The earliest name in the sequence is the one that describes the element actually interacted with, so it wins. Names that describe nothing are not cached at all: not every event in a sequence has a describable target, and one that doesn't would otherwise claim the timestamp and leave the span named `<unknown>`.
logaretm
force-pushed
the
awad/inp-element-name-first-write
branch
from
September 10, 2026 03:29
f1b239d to
5e012d5
Compare
Member
Author
|
bugbot run |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit 5e012d5. Configure here.
logaretm
marked this pull request as ready for review
September 10, 2026 05:04
logaretm
requested review from
Lms24 and
msonnb
and removed request for
a team
September 10, 2026 05:04
Lms24
approved these changes
Sep 10, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I noticed this while writing tests for the soft navs in #24273 and this changes the logic to grab the first available name and doesn't overwrite it with other candidates. again this was all best effort from the get go, so this adjusts this a bit more.
This only reproduces on Chromium 151+. Older versions happen to round the follow-up events to a different millisecond, which is why nothing caught it so far.
In a follow up when 153 is released we can rely on
targetSelectorproperty to get us the element name reliably.