RE: 答复: W3C Navigation Error Logging - log when UA crash/freeze?

We’ve been pretty careful to this point about including very little (no) user sensitive information in the error events. Although I would love to get the stack trace, I think that would require something like opting into a ‘Customer Experience Program’ that has informed consent. Stack traces from apps contain a lot of potentially sensitive information. Much more than the URL and other normal request information that we technically already have access to when a UA makes a request.

I was thinking about it just being a specific error type, say ‘Crash’ versus ‘DNS failure’, and we’d get the same information as other errors. The key being the URL that the crash occurred on.

Is there a safe subset of a trace that we could glean? Maybe a stack processor that makes a best guess on who’s at fault and just returns that much info (site or browser or webkit kernel or system lib).?



From: Liang,Tao [mailto:liangtao01@baidu.com]
Sent: Wednesday, October 22, 2014 5:35 PM
To: Ilya Grigorik
Cc: Aaron Heady (BING AVAILABILITY); public-web-perf@w3.org
Subject: 答复: 答复: W3C Navigation Error Logging - log when UA crash/freeze?

The situation is liking this: if ua crash, we need another thread or process to log the crash stack trace. And the stack trace will be sent to a server. Then it’s helpful to analyze the crash and to figure out who’s problem (site or browser or webkit kernel or system lib).

发件人: Ilya Grigorik [mailto:igrigorik@google.com]
发送时间: 2014年10月22日 23:29
收件人: Liang,Tao
抄送: Aaron Heady (BING AVAILABILITY); public-web-perf@w3.org<mailto:public-web-perf@w3.org>
主题: Re: 答复: W3C Navigation Error Logging - log when UA crash/freeze?

Aaron, Liang, do you have any existing data on size of the problem? Examples of how and where it helped?

I figure every browser maintains some internal tracking for crash counts (we do with Chrome), but it's not clear to me that this data is actionable for the developer. Many crashes have nothing to do with site's application code, and often times its hard to figure out who's at fault (site vs. browser bug, etc).

ig

On Wed, Oct 22, 2014 at 1:58 AM, Liang,Tao <liangtao01@baidu.com<mailto:liangtao01@baidu.com>> wrote:
I agree with Aaron Heady's advice. In fact, it's useful to see the release's effect on crash for global user base and to supply a way to improve the product.
But does Navigation have an opportunity to logging Crash / Breeze ?


-----邮件原件-----
发件人: Aaron Heady (BING AVAILABILITY) [mailto:aheady@microsoft.com<mailto:aheady@microsoft.com>]
发送时间: 2014年10月22日 4:25
收件人: public-web-perf@w3.org<mailto:public-web-perf@w3.org>
主题: RE: W3C Navigation Error Logging - log when UA crash/freeze?

Any thoughts on this?

-----Original Message-----
From: Aaron Heady (BING AVAILABILITY)
Sent: Tuesday, October 14, 2014 1:38 PM
To: 'public-web-perf@w3.org<mailto:public-web-perf@w3.org>'
Subject: W3C Navigation Error Logging - log when UA crash/freeze?

Curious about a possible addition to the scope of what logging covers. Does anything in the spec capture when a page load crashes the browser tab or causes it to be unresponsive? We ran into an obscure situation that we hadn’t tested for and managed to get a UA to crash, looks like it was related to a style recalculation.

Could we/should we log an error entry on the page/domain when the UA crashes/freezes, so we can see at scale that something we released is increased the crash/freeze rate for the global user base?

Thoughts?

Aaron