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/CAM0wra85yz4nFSJPj3wd5d1s7TWay1%2BLhpaohNA-KMkFQQr-Dg%40mail.gmail.com.
