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
On Thursday, January 25, 2024 at 8:05:14 AM UTC-8 Dave Tapuska wrote:
> 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 <dom...@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 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 <dtap...@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 <
>>>> blin...@chromium.org> wrote:
>>>>
>>>>> 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
>>>>> <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+...@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+...@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+...@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/f0ee10ea-759b-4c01-89e5-63bb2d34a94fn%40chromium.org.
