-
Notifications
You must be signed in to change notification settings - Fork 16.5k
feat: WebFrameMain.collectJavaScriptCallStack() #44204
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
Conversation
64e2d5c
to
9824088
Compare
9824088
to
5006bb8
Compare
Updated the API to do just that. cc @nornagon There are still some requirements to be able to collect the call stack:
|
docs/api/web-frame-main.md
Outdated
#### `frame.collectJavaScriptCallStack()` _Experimental_ | ||
|
||
Returns `Promise<string> | Promise<void>` - A promise that resolves with the currently running JavaScript call | ||
stack. If no JavaScript runs, the promise will never resolve. If the call stack is unable to be collected, it |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If no JavaScript runs, the promise will never resolve
Just curious, what is the better way to determine this case ? would checking for current stack position against the threads stack base address help ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Naively, would providing a timeout argument be helpful to provide users with an escape hatch?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
would checking for current stack position against the threads stack base address help ?
I think this would be best left as feedback (or a CL) upstream so it can be fixed there. We should mention this in https://issues.chromium.org/issues/40268201
javascript_call_stack_collector.cc is specifically where RequestInterrupt is invoked.
Naively, would providing a timeout argument be helpful to provide users with an escape hatch?
If a fix cannot be applied upstream, I think we should consider this. My thinking is we merge this as experimental for now and revisit after seeing results from usage.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍
// Enable features required by tests. | ||
app.commandLine.appendSwitch('enable-features', [ | ||
// spec/api-web-frame-main-spec.ts | ||
'DocumentPolicyIncludeJSCallStacksInCrashReports' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any reason to not enable this feature by default DocumentPolicyIncludeJSCallStacksInCrashReports
in the runtime ? Users are still required to opt-in respective documents via the policy header, just wondering if there is necessity to control the feature behind two runtime feature flags. Maybe in our case just the document policy is sufficient, thoughts ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Having this enabled by default would make it easier to automatically use this in the Sentry Electron SDK without the risk of clobbering users existing enable-features
switch.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't consider this given the early API availability in Chromium. It's estimated to be in origin trial until Chromium 132 and there hasn't been significant feedback by standards committees based on information provided in the Chrome Status page.
Assuming it's fully rolled out in Chromium 133, we could expect to not require the flag by Feb 4, 2025.
Maybe in our case just the document policy is sufficient, thoughts?
I'm not against it if folks are okay with this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good, we can revisit this again.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's more discussion about it here: #45356 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From a code implementation side, this looks good to me - the diff is relatively small and low-risk 👍 Approved pending API working group approval
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
API LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
API LGTM
PR should be good to merge, can you rebase on latest |
7bb871e
to
0abc73f
Compare
Release Notes Persisted
|
I have automatically backported this PR to "33-x-y", please check out #44937 |
I have automatically backported this PR to "34-x-y", please check out #44938 |
Description of Change
Adds
WebFrameMain.collectJavaScriptCallStack()
to allow accessing the JavaScript call stack of unresponsive renderers. This is available in Chromium as part of the Crash Reporting API.With this API, a dialog shown when a renderer becomes unresponsive could have an option to copy the stack trace. This would help application developers figure out why their website might be stuck on long-running JavaScript.
I've marked the API as experimental given that the proposal is still a draft.
Here's an example of the output from a fiddle gist:
Checklist
npm test
passesRelease Notes
Notes: Added
WebFrameMain.collectJavaScriptCallStack()
for accessing the JavaScript call stack of unresponsive renderers.