Intent to Experiment: Call stacks in crash reports from unresponsive web pages

509 views
Skip to first unread message

Issack John

unread,
Jul 8, 2024, 5:16:17 PMJul 8
to Digest recipients
Contact emails
Explainer
Specification
Design docs
Summary
This feature captures the JS call stack when a web page becomes unresponsive due to JavaScript code running an infinite loop or other very long computation. This helps developers to identify the cause of the unresponsiveness and fix it more easily. The JS call stack is included in the crash reporting API when the reason is unresponsive.


Blink component
TAG review
None

TAG review status


Risks


Interoperability and Compatibility
"The stack trace format itself is not compatible across browsers." However, "It is already exposed throughout the web platform (via the `error.stack` getter), and there is already a lot of software, both client- and server-side, which deals with parsing the different browsers' formats."


Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:

Security
Stack frames from cross-domain scripts that were not loaded with CORS must be omitted.


WebView application risks
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None


Goals for experimentation
The primary goal of this experiment is to gain insights on the usage and effectiveness of the call stacks in crash reports from unresponsive web pages feature. We aim to understand how this feature can help developers debug unresponsive renderers, and how it can be improved to better serve their needs. 

 Specifically, we are looking to gain insight on the following pieces of the API surface: 
 - The frequency under which the feature is used. 
- The usefulness of the call stacks provided by this feature in debugging unresponsive renderers. 

 To validate our designs, we will be using the following metrics and feedback: 
 - Usage data: We will collect data on the number of execution contexts for which this feature is enabled, and the call stack is generated. 
- Developer feedback: We will solicit feedback from developers on the usefulness of the call stacks provided by this feature, and any improvements they would like to see.

Ongoing technical constraints
None


Debuggability
Developers can launch DevTools, go to the "Application" Tab, then in the "Background services" section click on "Reporting API" where they can inspect reports that are queued to be sent. Application --> Reporting API


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?
Yes

Is this feature fully tested by web-platform-tests?
No
This feature is not currently testable on WPT, since triggering it requires crashing the browser.


DevTrial instructions
Flag name on chrome://flags


Finch feature name
DocumentPolicyIncludeJSCallStacksInCrashReports

Requires code in //chrome?
False

Tracking bug
Estimated milestones
Origin trial desktop first
127
Origin trial desktop last
132
DevTrial on desktop
125
OriginTrial Android last
132
OriginTrial Android first
127
DevTrial on Android
125
OriginTrial webView last
132
OriginTrial webView first
127


Link to entry on the Chrome Platform Status
Links to previous Intent discussions
This intent message was generated by Chrome Platform Status.

Domenic Denicola

unread,
Jul 11, 2024, 2:17:09 AMJul 11
to Issack John, Digest recipients
Can you work on filing for TAG review, and asking other browsers for signals?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/BL0PR00MB07408CC83936B9049010FBF7C2D02%40BL0PR00MB0740.namprd00.prod.outlook.com.

Yoav Weiss (@Shopify)

unread,
Jul 11, 2024, 7:09:29 AMJul 11
to Domenic Denicola, Issack John, Digest recipients
LGTM to experiment M127-M132 inclusive.

On Thu, Jul 11, 2024 at 8:17 AM Domenic Denicola <dom...@chromium.org> wrote:
Can you work on filing for TAG review, and asking other browsers for signals?

I agree it's a good idea to file all these at this point, but they are not a blocker for an initial OT request. (they would be for extensions, along with spec work)
 

Issack John

unread,
Jul 11, 2024, 1:16:36 PMJul 11
to blink-dev, yoav...@chromium.org, Issack John, Digest recipients, dom...@chromium.org
I'll work on filing for the TAG review and asking other browsers for signals. Thanks!

Issack John

unread,
Aug 7, 2024, 2:59:42 PMAug 7
to blink-dev, Issack John, yoav...@chromium.org, Digest recipients, dom...@chromium.org
An important note is that chromium "does not support using any RuntimeFeatureState-based OT via header request. These OTs MUST be provided via meta tag to work correctly.".

Issack John

unread,
Sep 16, 2024, 1:34:28 PMSep 16
to blink-dev, Issack John, yoav...@chromium.org, Digest recipients, dom...@chromium.org
This Origin Trial will now support opting in via any of the methods. A fix was landed as of 130.0.6675.0. You can opt in using any of the following methods:

Meta Tag: Include a meta tag in the <head> of your HTML document.
HTTP Header: Add an HTTP header in the server response.
Programmatically: Provide the token programmatically within your code.
Reply all
Reply to author
Forward
0 new messages