Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Use frame.collectJavaScriptCallStack() for renderer ANR in Electron >= v34 #1105

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

timfish
Copy link
Collaborator

@timfish timfish commented Mar 20, 2025

Previously, renderer process "App Not Responding" events captured stack traces via the Electron debugging API.

Since Electron v34, the frame.collectJavaScriptCallStack() API has been added which lets us capture stack traces via the same code used for Chromium's proposed Crash Reporting API.

This PR:

  • Adds an internal function to capture StackFrame[] from a renderer
    • captureRendererStackFrames(webContents: WebContents): Promise<StackFrame[]>
    • We could also export this function so users could use it elsewhere? Users might want to use it with Electrons unresponsive events rather than our own ANR detection?
  • Adds an new top-level option enableRendererStackCapture that enables this Chromium feature and injects the required Document-Policy headers
  • If this feature is enabled and the Electron version is >= v34, we use the new native API rather than the debugger.

To enable this feature for renderer ANR:

Main process:

import * as Sentry from "@sentry/electron/main";

Sentry.init({
  dsn: "__DSN__",
  enableRendererStackCapture: true
});

Renderer process:

import * as Sentry from "@sentry/electron/renderer";

Sentry.init({
  anrDetection: { captureStackTrace: true },
});

Why a new top-level option?

I would rather have zero configuration for this feature but since it requires headers to be injected before the page loads, I felt that this was the only reasonable option. We already have a top level option to enable js-profiling because this also requires injection of headers.

Should captureStackTrace default to true?

Since this feature no longer uses the debugger, we might want to captureStackTrace: true the default in this case? When would you not want stack traces?

@timfish timfish marked this pull request as ready for review March 20, 2025 21:18
@timfish timfish requested a review from AbhiPrasad March 20, 2025 21:18
Copy link
Member

@AbhiPrasad AbhiPrasad left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we re-evaluate the enableRendererStackCapture name? It seems confusing to me, especially because marking it undefined will still cause the integration to work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Make use of frame.collectJavaScriptCallStack() for renderer ANR
2 participants