RE: [ErrorLogging] Draft Specification

Pan,

Based on last week's conference call, we decided to create a separate object for historical error data that only specifies document errors from previous navigations, and a separate object for document and resource errors on the current document. Only the historical document error data would be persisted across sessions.

I'll share out an updated version of the spec with those changes.

Thanks,
Jatinder

From: Deng, Pan [mailto:pan.deng@intel.com]
Sent: Tuesday, April 9, 2013 1:13 AM
To: 'public-web-perf@w3.org'
Subject: RE: [ErrorLogging] Draft Specification

I've observed that one problem resource fetching blocked "onload" event and affected site browsing performance, very glad to see ErrorLogging would help:).

Some thoughts for current draft:
[1] About how to access historical error data. As previous discussion, historical error data will be separated from that of current session, I think they can also exposed through performance timeline via a new entryType (like "previous_error"), and specified clear/buffer method that in performance object. One benefit is flexible control in script level, another is the interface is consistent with previous spec.

[2] About how current error data become historical? In my opinion, when browser leaves a session, error data that live in current buffer should be persisted, while the cleared won't, in that way the unhandled data can be accessed in future and the handled won't take up buffer. In addition, error data of incomplete resource fetching should also be persisted (to track the request which is problematic but haven't been populated to current buffer yet).

Thanks
Pan