Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gather Diagnostic Data #33

Open
aluhrs13 opened this issue Aug 8, 2022 · 3 comments
Open

Gather Diagnostic Data #33

aluhrs13 opened this issue Aug 8, 2022 · 3 comments

Comments

@aluhrs13
Copy link

aluhrs13 commented Aug 8, 2022

Use case name

Diagnostics

Submitter(s)

Andy Luhrs

Motivation

App developers need to understand the fundamentals (performance and reliability in this context) of their applications. Hybrid applications oftentimes add difficulty to this, as native platforms are tailored to give them insights on native fundamentals, but don't have visibility into the fundamentals of their web content. It's generally possible to use web standard APIs like Performance Timeline and Reporting API to get and understanding of web fundamentals then correlate those to other native data, but that could be lossy and/or difficult.

Stakeholders

App developers and end-users.

Analysis

WebView2 has a handful of useful APIs in this area:

  • Process Failed: Allows developers to listen for an event if any of the processes in the WebView crashes or hangs.
  • Add Script On Document Create: Allows developers to inject and run JavaScript at document creation, which can be used to setup performance or reporting observers that send data to the host application. (there's a handful of other WV2 APIs to run JS that could be used for this too)
  • Call DevTools Protocol: Allows developers to run arbitrary Chrome DevTools Protocol (CDP) commands and listen to CDP events. This lets them perform pretty much any activity that a browser's DevTools would do such as observing memory usage, starting performance tracing, or listening to console output.

Related W3C deliverables and/or work items

Performance Timeline and Reporting API are the most notable.

How is the issue solved in the Browser, and what’s more is needed?

When investigating issues locally, web developers have access to various developer tools and sites varying by browser. Data at-scale generally uses the JS APIs above.

@aluhrs13
Copy link
Author

aluhrs13 commented Aug 8, 2022

I'm not super familiar with mobile APIs here and wanted to get this use-case written before a long vacation, @rayankans happy to take input on what Android has or I can look deeper in a couple weeks.

@QingAn
Copy link
Contributor

QingAn commented Aug 23, 2022

As discussed in 2022-08-23 meeting, please add some details about the other platforms, like Android WebView, etc. @rayankans @aluhrs13

@rayankans
Copy link
Contributor

Android WebView:

  • The WebView runs as part of the host app's process. Any crashes in the browser process would crash the app
  • Developers can listen to events on the renderer process

Custom Tabs:

  • There are no direct events that report crashes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants