Yes I was thinking of how the stack trace format was standardized as well. How do wasm call stacks work with this proposal?
dave. On Wed, Jan 24, 2024 at 8:27 PM Domenic Denicola <dome...@chromium.org> wrote: > 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. > > On Thu, Jan 25, 2024 at 5:59 AM Rick Byers <rby...@chromium.org> wrote: > >> 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 <iclell...@chromium.org> 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 >> <https://wicg.github.io/js-self-profiling/>? 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 >> >> On Wed, Jan 24, 2024 at 3:10 PM Dave Tapuska <dtapu...@chromium.org> >> wrote: >> >>> 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. >>> >>> On Wed, Jan 24, 2024 at 12:47 PM 'Issack John' via blink-dev < >>> blink-dev@chromium.org> wrote: >>> >>>> Contact emails >>>> issackj...@microsoft.com, seth.bren...@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 >>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EReportingObserver> >>>> >>>> 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 >>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>> ? >>>> 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 >>>> <https://chromestatus.com/>. >>>> >>>> -- >>>> 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+unsubscr...@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 >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/MW2PPF6784DDB763E2DA7BFC75AE51613ABC27B2%40MW2PPF6784DDB76.namprd00.prod.outlook.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >>> 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+unsubscr...@chromium.org. >>> 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 >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHgVhZUui22mB-J5SAEmEd%3DCk%2BrcyRSr4tGASLGFcsvRn9QVOQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- >> 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+unsubscr...@chromium.org. >> To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_LQuaFsJXuQvBnwrJUjQeHnsya6QENTVVW9mkkrO26OA%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_LQuaFsJXuQvBnwrJUjQeHnsya6QENTVVW9mkkrO26OA%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- 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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHgVhZXmpxUmoa3bmPNiTAY-iDgiu6B-Mr-p9c7dSfZWHbNGMg%40mail.gmail.com.
