+
Skip to content

Conversation

samuelmaddock
Copy link
Member

@samuelmaddock samuelmaddock commented Oct 11, 2024

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:

Renderer unresponsive
 
    at startInfiniteLoop (<anonymous>:5:5)
    at HTMLHtmlElement.clickHandler (<anonymous>:11:5)

Checklist

Release Notes

Notes: Added WebFrameMain.collectJavaScriptCallStack() for accessing the JavaScript call stack of unresponsive renderers.

@electron-cation electron-cation bot added the new-pr 🌱 PR opened recently label Oct 11, 2024
@samuelmaddock samuelmaddock added the target/33-x-y PR should also be added to the "33-x-y" branch. label Oct 11, 2024
@samuelmaddock samuelmaddock added the semver/minor backwards-compatible functionality label Oct 11, 2024
@samuelmaddock samuelmaddock marked this pull request as ready for review October 11, 2024 15:31
@github-actions github-actions bot added the target/34-x-y PR should also be added to the "34-x-y" branch. label Oct 15, 2024
@electron-cation electron-cation bot removed the new-pr 🌱 PR opened recently label Oct 18, 2024
@samuelmaddock
Copy link
Member Author

If we have the APIs to be able to collect a call stack at any time, let’s expose that!

Updated the API to do just that. cc @nornagon

There are still some requirements to be able to collect the call stack:

  • JavaScript must be running. Otherwise the RequestInterrupt never resolves.
  • The webpage owner needs to enable the document-policy header defined by the crash reporting API
  • The origin trial needs to be enabled or the DocumentPolicyIncludeJSCallStacksInCrashReports chromium flag.

@samuelmaddock samuelmaddock changed the title feat: WebFrameMain.unresponsiveDocumentJSCallStack feat: WebFrameMain.collectJavaScriptCallStack() Nov 12, 2024
#### `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
Copy link
Member

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 ?

Copy link
Member

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?

Copy link
Member Author

@samuelmaddock samuelmaddock Nov 21, 2024

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.

Copy link
Member

@deepak1556 deepak1556 left a 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'
Copy link
Member

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 ?

Copy link
Contributor

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.

Copy link
Member Author

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.

Copy link
Member

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.

Copy link
Member

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)

Copy link
Member

@VerteDinde VerteDinde left a 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

Copy link
Member

@erickzhao erickzhao left a comment

Choose a reason for hiding this comment

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

API LGTM

Copy link
Member

@itsananderson itsananderson left a comment

Choose a reason for hiding this comment

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

API LGTM

@deepak1556
Copy link
Member

PR should be good to merge, can you rebase on latest main

@deepak1556 deepak1556 merged commit 2222920 into main Dec 3, 2024
53 checks passed
@deepak1556 deepak1556 deleted the feat/crash-call-stack branch December 3, 2024 04:32
@release-clerk
Copy link

release-clerk bot commented Dec 3, 2024

Release Notes Persisted

Added WebFrameMain.collectJavaScriptCallStack() for accessing the JavaScript call stack of unresponsive renderers.

@trop
Copy link
Contributor

trop bot commented Dec 3, 2024

I have automatically backported this PR to "33-x-y", please check out #44937

@trop trop bot added in-flight/33-x-y and removed target/33-x-y PR should also be added to the "33-x-y" branch. labels Dec 3, 2024
@trop
Copy link
Contributor

trop bot commented Dec 3, 2024

I have automatically backported this PR to "34-x-y", please check out #44938

@trop trop bot added in-flight/34-x-y merged/33-x-y PR was merged to the "33-x-y" branch. merged/34-x-y PR was merged to the "34-x-y" branch. and removed target/34-x-y PR should also be added to the "34-x-y" branch. in-flight/33-x-y in-flight/34-x-y labels Dec 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api-review/approved ✅ merged/33-x-y PR was merged to the "33-x-y" branch. merged/34-x-y PR was merged to the "34-x-y" branch. semver/minor backwards-compatible functionality
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants
点击 这是indexloc提供的php浏览器服务,不要输入任何密码和下载