<trackbot> Date: 01 May 2013

Update on Existing Spec Status

Plh: Page Visibility should be published as a recommendation next Thursday.
... We expect that this will take push finalizing the charter by a bit.

Feedback on Timing specs

Jatinder: Let's discuss onresourcebufferfull callback simplifications.

Arvind: I've updated the spec based on feedback. The spec wasn't clear if the callback should be called every time another entry is added; I didnt think that was the intention, so I updated the spec. I also updated the N+1 and N buffer size issue for the callback.

Jatinder: I think we have consensus here.
... Arvind raised updating the definition of navigationStart in navigation timing when there is no previous document (new tab scenario). Can we get a test case that shows the redirect time? Looks like IE10 implements the spec; I want to understand this change first.

Arvind: Looks like in Chrome opening a new tab page and navigating to a page doesn't count as not having an unload. If you open the page by clicking open new tab, you should open a page with no unload.

Jatinder: Are we suggesting in that case where there isn't an unload, there is a redirect, navigationStart should be equal to redirectStart, otherwise fetchStart?

Arvind: That sounds right.
... What options do we have?

Plh: We can make the change in NT L2, or add an addendum to L1

Resource Timing Test Cases

Jatinder: I shared feedback on the Resource Timing test cases. I recommend approving 14 of the test cases as is. I wanted to discuss the others. The mail thread is here: http://lists.w3.org/Archives/Public/public-web-perf/2013May/0004.html
... http://w3c-test.org/webperf/tests/submission/Google/resource-timing/html/test_resource_cached.html
... This test case fetches 2 identical resources (with different query strings) to test if a 304 will create an entry. Looks like the test case expects a duplicate entry to be created, even though I would expect that we do not create a resource timing entry for the duplicate. Is this because the query string is different? Is Icon.png a different fetch from icon.png even if it's the same resource on the server?
... http://w3c-test.org/webperf/tests/submission/Google/resource-timing/html/test_resource_ignore_failures.html
... This test fetches a resource that doesn't exist (returns 404) and is expecting 0 resource timing entries. Looks like the test expects that the entry shouldn't be created. I wanted clarification if step 3.7 (if fetching the resource is aborted for any reason, abort the remaining step) means that we should not add this entry. Seems like it.

James: We should clarify that "aborted" includes HTTP errors.

plh: We should be consistent here between the two network requests.

James: With the 304, technically we are blocked waiting for the network response. The 404 you can never use it.

Jatinder: Let's follow up on these two on the list.
...

http://w3c-test.org/webperf/tests/submission/Intel/resource-timing/test_resource_timing_buffer_size_restriction.html.

This test cases creates 3 resources before ResourceTimingBufferSize is set to 2. Per spec text, "if the maxSize parameter is less than the number of elements currently stored in the buffer, no elements in the buffer are to be removed. The maxSize parameter will apply only after the clearResourceTimings method is called." The number of entries won't be truncated if they exist before a lesser buffer size is set

Jatinder: There are some onresourcebufferfull test cases that we should make sure are still accurate after the spec changes.

James: I'll follow up with Pan and fix these test cases.

Arvind: I wanted to discuss navigationStart in the Navigation Timing L2 spec.
... There is already a startTime equal to 0.0. navigationStart definition is redundant. I recommend we cut it.

Error Logging

<JatinderMann_> Arvind: Seems like it is most appropriate if the initial buffer size was set to zero, and the developer could enable the feature by changing the buffer size.

<JatinderMann_> Aaron: That seems reasonable.

<JatinderMann_> Arvind: I don't think we should reuse Performance Timeline for Navigation Error Logging, as Performance Timeline defines startTime to be the start of the recorded event. Since this is historical, doesn't make sense.

<JatinderMann_> Jatinder: We could specify a different performance.getErrorEntries that's different from performance.getEntries? Resource Errors could use getErrorEntries as well, but it would need to use DOMHighResTimeStamp.

<JatinderMann_> Arvind: The errorType should also only be "dns", "tcp", "tls", "http".

<JatinderMann_> Jatinder: Aaron, have you seen any errors outside of these?

<JatinderMann_> Aaron: These are the only ones that come to mind.

<JatinderMann_> Arvind: For Navigation Error Logging, I don't think we need to define an onnavigationerrorbufferfull, because the first time JavaScript runs, you can pull down all the details. The buffer should never be filled.

<JatinderMann_> Aaron: Considering we talked about simplifying the callback for Resource Timing, this seems reasonable.

<JatinderMann_> Jatinder: Okay, we should remove it.

TPAC Attendance

<JatinderMann_> Arvind: Let's meet at TPAC this year.