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

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

['Issack John' via blink-dev]

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.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/BL0PR00MB07408CC83936B9049010FBF7C2D02%40BL0PR00MB0740.namprd00.prod.outlook.com.