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

[Issack John]

Contact emails

issac...@microsoft.com, seth.b...@microsoft.com

Explainer

https://github.com/WICG/crash-reporting/issues/12

Specification

https://docs.google.com/document/d/19DpvHIiYbmB9wgIP0BdI4vOnfVLcAZFmfIAml7SqRQA/edit?usp=sharing

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

Blink>ReportingObserver

Motivation

When a web page becomes unresponsive, it's often because of JavaScript code which is busy running an infinite loop or other very long computation. When a developer receives a report from the crash reporting API, and the reason is unresponsive, it would be very helpful to include the JS call stack from when the page was deemed unresponsive. This would let the website developer more easily find the find and fix the problem. What happens instead? The page reports that it was terminated due to being unresponsive, but the developer of the page has no further information about how to fix the problem.

Initial public proposal

https://bugs.chromium.org/p/chromium/issues/detail?id=1445539

TAG review

None

TAG review status

Pending

Risks

Interoperability and Compatibility

None

Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:

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

Debuggability

None

Is this feature fully tested by web-platform-tests?

No

Flag name on chrome://flags

None

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1445539

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4731248572628992

This intent message was generated by Chrome Platform Status.

[Dave Tapuska]

Just a few thoughts...

I haven't seen a proposed implementation but I presume you are going to restrict this only to execution stacks in the main world? 

If you get an extension executing scripts in the main world how will you prevent the endpoint from knowing about the agent's execution environment such as what extensions they have installed?

How do you know from the IO thread what the main thread isolate is? (blink::MainThreadIsolate is deprecated, please don't use it).

How do document policies work across same origin documents? What realms are you checking that the policy applies, do you walk the stack looking at realms and checking if the policies apply? Or is it the current realm or incumbent realm or what? 

dave.

--
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/MW2PPF6784DDB763E2DA7BFC75AE51613ABC27B2%40MW2PPF6784DDB76.namprd00.prod.outlook.com.

[Rick Byers]

Not to distract from Dave's good technical questions. But I just wanted to say that I'm quite excited about this work - I think it's an important capability for any serious platform to have that app developers can get actionable crash and hang reports, and this has been a gap. Thank you for working on it! Don't hesitate to reach out if I can help unblock progress in any way.

What you have listed as a spec is more of a design doc so you'll eventually need a formal spec. But the reporting spec editor @Ian Clelland mentioned over breakfast to me today that he was helping to support this work, so that's great to hear.

Dave's question about extensions in the main thread and privacy implications is a good one. My initial personal take is that we probably shouldn't report from extension isolated worlds, but when an extension injects script into the main world, I think I can argue that they're explicitly informing the site developer about their presence. In practice I believe sites can detect such extensions already if suitably motivated (eg. hook into the prototype of various APIs and identify their calling patterns or look at JS exception stack traces). I can see an argument for not giving sites easy access to such information in real-time and wonder if this has come up already for the self-profiling API proposal? But for an asynchronous crash report sent only after the page has been shut down, I personally don't think it's a threat we should be trying to defend against. I'd go even further and say that if a site is hanging or crashing only under the presence of extension-injected code in the main world, then that's critical information for the site owner to know from a customer support perspective.

Rick

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHgVhZUui22mB-J5SAEmEd%3DCk%2BrcyRSr4tGASLGFcsvRn9QVOQ%40mail.gmail.com.

[Domenic Denicola]

I agree with Dave's take on the importance of not including extension scripts themselves, and Rick's take on how it is OK to include extension-injected main world scripts.

One additional interop concern that's worth highlighting here is that the stack trace format itself is not compatible across browsers. However, I don't think that should block this intent. 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. I don't think this would make the situation any worse.

I do wish that one day browsers would get together and standardize the stack trace format. https://github.com/tc39/proposal-error-stacks is one attempt at that, but it has been largely dormant for 3 years.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_LQuaFsJXuQvBnwrJUjQeHnsya6QENTVVW9mkkrO26OA%40mail.gmail.com.

[Dave Tapuska]

Yes I was thinking of how the stack trace format was standardized as well. How do wasm call stacks work with this proposal?

dave.

[Issack John]

Hi all, 

Thank you for the great questions and insights. 

This feature will be restricted to only the execution stacks in the main world. As Rick described, extension code injected into the main world may be visible.

How do you know from the IO thread what the main thread isolate is?

Because blink::MainThreadIsolate is deprecated, I believe we have some options.

1. V8::PerIsolateData::MainThreadIsolate, unless that is also deprecated. (No code comment saying that it is.)

2. MainThreadSchedulerImpl::ForEachMainThreadIsolate(base::RepeatingCallback<void(v8::Isolate* isolate)> callback)

    Currently, this function only calls the callback for a single isolate but IIUC, we can check if the isolate has a main world and that would be the main thread isolate?

The design document now includes the questions that I have received. I am working on getting more information to address the remaining technical questions.

Issack

[Dmitry Gozman]

While reviewing the proposed implementation, I had the following privacy-related concern, and would like to consult the API owners on the topic.

When capturing the stack trace in the renderer process, we do not attribute it to the page/frame that is actually running JS. Therefore, when two pages or cross-origin frames share the same renderer, we could capture a stack trace in one of them, and accidentally send it to the crash reporting endpoint from the other.

I wonder whether we consider this a risk? If we do, any ideas about mitigating it? For example, we could probably restrict this feature to renderers that are known to only host a single origin (not yet sure whether that's easily known), so that we cannot mistakenly capture a different origin stack trace. Or maybe someone knows how to attribute a stack trace to the originating frame?

Thank you,

Dmitry

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f0ee10ea-759b-4c01-89e5-63bb2d34a94fn%40chromium.org.

[Rick Byers]

Yikes, that definitely sounds like a potential privacy issue to me Dmitry, thanks! I added it as a question in the design doc, let's take the discussion there rather than blink-dev?

Rick 

[Jacob Goldman]

Hi all,

This sort of reporting would be incredibly useful for third-party Javascript given how widely it is deployed and potentially dangerous an infinite loop in that context could be. I'm an engineer who writes third-party JavaScript for Google's Display Ads products and having capabilities like this built-in to the browser would enhance our confidence in the safety of the code our publishers entrust us to run on their sites.

To that end, we would like to request that the specification further incorporate reporting from hung third-party JavaScript executing within the top-level browsing context. Specifically, we would like to explore the possibility of an additional opt-in mechanism on cross-origin scripts, possibly through a similar mechanism to Heavy Ad Intervention via Report-To. Upon observing a crash, the user agent would only send reports to an origin after searching the call stack for a frame belonging to the corresponding origin.

Overall, we’re quite excited about this proposal and would be interested in partnering on a joint origin trial if third-party scripts could be incorporated into the spec.

Thanks,

Jacob