Re: [blink-dev] Intent to Experiment: Call stacks in crash reports from unresponsive web pages

['Issack John' via blink-dev]

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.".

On Thursday, July 11, 2024 at 10:16:36 AM UTC-7 Issack John wrote:

> I'll work on filing for the TAG review and asking other browsers for 
> signals. Thanks!
>
> On Thursday, July 11, 2024 at 4:09:29 AM UTC-7 yoav...@chromium.org wrote:
>
>> LGTM to experiment M127-M132 inclusive.
>>
>> On Thu, Jul 11, 2024 at 8:17 AM Domenic Denicola  
>> 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)
>>  
>>
>>>
>>> On Tue, Jul 9, 2024 at 6:16 AM 'Issack John' via blink-dev <
>>> blin...@chromium.org> wrote:
>>>
 Contact emails
 issac...@microsoft.com, seth.b...@microsoft.com

 Explainer

 https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/CrashReporting/AddStackToCrashReports.md
 https://github.com/WICG/crash-reporting/issues/12

 Specification
 https://wicg.github.io/crash-reporting

 Design docs


 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
 Chromium > Internals > Network > ReportingAndNEL 
 

 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

 https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/CrashReporting/HOWTO.md

 Flag name on chrome://flags


 Finch feature name
 DocumentPolicyIncludeJSCallStacksInCrashReports

 Requires code i

Re: [blink-dev] Intent to Experiment: Call stacks in crash reports from unresponsive web pages

['Issack John' via blink-dev]

I'll work on filing for the TAG review and asking other browsers for 
signals. Thanks!

On Thursday, July 11, 2024 at 4:09:29 AM UTC-7 yoav...@chromium.org wrote:

> LGTM to experiment M127-M132 inclusive.
>
> On Thu, Jul 11, 2024 at 8:17 AM Domenic Denicola  
> 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)
>  
>
>>
>> On Tue, Jul 9, 2024 at 6:16 AM 'Issack John' via blink-dev <
>> blin...@chromium.org> wrote:
>>
>>> Contact emails
>>> issac...@microsoft.com, seth.b...@microsoft.com
>>>
>>> Explainer
>>>
>>> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/CrashReporting/AddStackToCrashReports.md
>>> https://github.com/WICG/crash-reporting/issues/12
>>>
>>> Specification
>>> https://wicg.github.io/crash-reporting
>>>
>>> Design docs
>>>
>>>
>>> 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
>>> Chromium > Internals > Network > ReportingAndNEL 
>>> 
>>>
>>> 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
>>>
>>> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/CrashReporting/HOWTO.md
>>>
>>> Flag name on chrome://flags
>>>
>>>
>>> Finch feature name
>>> DocumentPolicyIncludeJSCallStacksInCrashReports
>>>
>>> Requires code in //chrome?
>>> False
>>>
>>> Tracking bug
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1445539
>>>
>>> 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
>>> Orig

Re: [blink-dev] Intent to Experiment: Call stacks in crash reports from unresponsive web pages

[Yoav Weiss (@Shopify)]

LGTM to experiment M127-M132 inclusive.

On Thu, Jul 11, 2024 at 8:17 AM Domenic Denicola 
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)


>
> On Tue, Jul 9, 2024 at 6:16 AM 'Issack John' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Contact emails
>> issackj...@microsoft.com, seth.bren...@microsoft.com
>>
>> Explainer
>>
>> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/CrashReporting/AddStackToCrashReports.md
>> https://github.com/WICG/crash-reporting/issues/12
>>
>> Specification
>> https://wicg.github.io/crash-reporting
>>
>> Design docs
>>
>>
>> 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
>> Chromium > Internals > Network > ReportingAndNEL
>> 
>>
>> 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
>>
>> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/CrashReporting/HOWTO.md
>>
>> Flag name on chrome://flags
>>
>>
>> Finch feature name
>> DocumentPolicyIncludeJSCallStacksInCrashReports
>>
>> Requires code in //chrome?
>> False
>>
>> Tracking bug
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1445539
>>
>> 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
>> https://chromestatus.com/feature/4731248572628992?gate=5542684580380672
>>
>> Links to previous Intent discussions
>> Intent to prototype:
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/MW2PPF6784DDB763E2DA7BFC75AE51613ABC27B2%40MW2PPF6784DDB76.namprd00.pr

Re: [blink-dev] Intent to Experiment: Call stacks in crash reports from unresponsive web pages

[Domenic Denicola]

Can you work on filing for TAG review, and asking other browsers for
signals?

On Tue, Jul 9, 2024 at 6:16 AM 'Issack John' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emails
> issackj...@microsoft.com, seth.bren...@microsoft.com
>
> Explainer
>
> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/CrashReporting/AddStackToCrashReports.md
> https://github.com/WICG/crash-reporting/issues/12
>
> Specification
> https://wicg.github.io/crash-reporting
>
> Design docs
>
>
> 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
> Chromium > Internals > Network > ReportingAndNEL
> 
>
> 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
>
> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/CrashReporting/HOWTO.md
>
> Flag name on chrome://flags
>
>
> Finch feature name
> DocumentPolicyIncludeJSCallStacksInCrashReports
>
> Requires code in //chrome?
> False
>
> Tracking bug
> https://bugs.chromium.org/p/chromium/issues/detail?id=1445539
>
> 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
> https://chromestatus.com/feature/4731248572628992?gate=5542684580380672
>
> Links to previous Intent discussions
> Intent to prototype:
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/MW2PPF6784DDB763E2DA7BFC75AE51613ABC27B2%40MW2PPF6784DDB76.namprd00.prod.outlook.com
>  Ready
> for Trial:
> https://groups.google.com/a/chromium.org/g/blink-dev/c/aVpeVRO1Sy4
>
>
> This intent message was generated by Chrome Platform Status
> .
>
> --
> 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.o