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 <dom...@chromium.org> 
>> 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 
>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Chromium%20%3E%20Internals%20%3E%20Network%20%3E%20ReportingAndNEL>
>>>>
>>>> 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 
>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>>>> ?
>>>> 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 
>>>> <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/BL0PR00MB07408CC83936B9049010FBF7C2D02%40BL0PR00MB0740.namprd00.prod.outlook.com
>>>>  
>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/BL0PR00MB07408CC83936B9049010FBF7C2D02%40BL0PR00MB0740.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/CAM0wra-WmZqSk%3DE_5h5fQmXDFEEP2y8o44gZeU9%2B6zB_JwVftA%40mail.gmail.com
>>>  
>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra-WmZqSk%3DE_5h5fQmXDFEEP2y8o44gZeU9%2B6zB_JwVftA%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/f43b4e9f-5af8-4c4b-bcd9-342332dd57edn%40chromium.org.

Reply via email to