fix(browser): Defer sending session envelope until browser is idle#21844
Merged
Conversation
Contributor
size-limit report 📦
|
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 9de6194. Configure here.
logaretm
approved these changes
Jun 29, 2026
When using the default `lifecycle: 'route'`, a navigation that happens before the deferred initial `whenIdleOrHidden` callback fires already starts and sends a new session. The deferred callback then re-sent that same (current) session, producing a duplicate envelope. Guard the deferred capture so it skips once a session has been sent, and mark the session as sent in the navigation handler. Co-Authored-By: Cursor Agent <cursoragent@cursor.com> Co-authored-by: Cursor <cursoragent@cursor.com>
Replace the inline `import()` type annotation in the browserSession unit test with a top-level type import to satisfy `consistent-type-imports`. Reorder the expected logs in the debug integration test: now that the initial session capture is deferred, the "Discarded session" warning is emitted after the `BrowserSession` integration is installed rather than before it. Co-Authored-By: Cursor Agent <cursoragent@cursor.com> Co-authored-by: Cursor <cursoragent@cursor.com>
The deferred browser session capture schedules a `whenIdleOrHidden` timer that calls `WINDOW.removeEventListener` when it fires. These nextjs tests stub a fake window with `addEventListener` but not `removeEventListener`, so the deferred timer threw an unhandled `TypeError` after the test. Stub and restore `removeEventListener` alongside `addEventListener`. Co-Authored-By: Cursor Agent <cursoragent@cursor.com> Co-authored-by: Cursor <cursoragent@cursor.com>
87bc0d0 to
dadb1bb
Compare
mydea
reviewed
Jun 30, 2026
| let originalDocument: unknown; | ||
| let originalLocation: unknown; | ||
| let originalAddEventListener: unknown; | ||
| let originalRemoveEventListener: unknown; |
Member
Author
There was a problem hiding this comment.
yes, it needs to be pulled in because whenIdleOrHidden registers and removes event listeners
mydea
approved these changes
Jun 30, 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
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.

Uses the
whenIdleOrHiddencallback to send the initial session envelope when the browser has some idle time or at the latest, when the page is hidden. For old Safari versions, we fall back tosetTimeoutbut otherwise we userequestIdleCallback(both withinwhenIdleOrHidden).This should improve initial SDK initialization performance as well as reduce implicitly caused overhead (like increased LCP), due to the eagerly sent network request.
This should be a fairly safe change to make. I don't think we risk loosing a lot of sessions with it, given RIC should fire relatively soon. At the same time, I'm curious how much it improves lighthouse scores (which we can check easiest after merging).
closes #21817