[minutes] 20110525 Web Performance WG Teleconference #34

Meeting Summary:



1.      Discussed feedback and updates to the Navigation Timing spec

a.       Incorrect description for requestStart

Navigation Timing spec implicitly called included local resources scenarios that should have not been included. Section 4.2 Interface definition and 5.1 Processing Model were updated. ACTION-34 has been opened on Zhiheng to make the same change to Resource Timing. Nic and Jatinder to review this change more thoroughly; though, based on explanation on the call, the change looks correct.



2.      Discussed feedback and updates to the Resource Timing spec

a.       Resource Timing has reached FPWD

Thanks to everyone's effort, Resource Timing has reached FPWD. Per feedback from last week's call and the mailing list, many fixes went into the FWPD draft, including those described on the mailing list: http://lists.w3.org/Archives/Public/public-web-perf/2011May/0107.html,  http://lists.w3.org/Archives/Public/public-web-perf/2011May/0114.html.



b.       Agreed to update the definition of initiator types to reference types of elements included

We agreed to update the spec to make it clear which type of elements are to be included in initiator types. ACTION 32 Update initiator types definitions to include elements that are included in that initiator types opened on Jatinder.



c.        Agreed to include a reference to what the expected behavior is with plugins.

We agreed that the spec needs to be more clear into what the expected behavior is around plugins. ACTION 33- Update spec to include a reference to what the expected behavior with plugins opened on Jatinder.


d.       Privacy Review of Resource Timing

The IE team had internally conducted a security review of the Resource Timing feature and did not find any significant issues. The WG agrees that we should not additional privacy features into the Resource Timing spec unless we agree there is a privacy concern.


e.       Taking Resource Timing to Last Call

We agreed that now the spec is a stable state, we will enter Last Call next week. If the Action Items opened in this call are sufficiently closed out by end of this week, we will target entering Last Call on June 2nd. Last Call period will be between June 2nd - June 30th.



If we can't close out our open Action items before Last Call, the WG can choose to push out the Last Call start period.


3.      Discussed feedback and updates to the User Timing spec

a.       Proposal to update User Timing interface

Nic, Jatinder and Karen had reviewed Tony's proposal and sent out a summary of advantages and disadvantages to the proposal - http://lists.w3.org/Archives/Public/public-web-perf/2011May/0112.html. Tony is to review this proposal and get back to the WG next week. In summary, there are three scenarios where the proposed interface leads to more work for developers or potential confusion: multi-phase scenarios, retrieving only marks or measures, finding the durations of a specific scenario.



Once we have closed on this proposal, we can consider taking this spec to First Public Working Draft.



4.      Discussed feedback and updates to the Page Visibility spec.

a.       Privacy Concerns with Page Visibility

Considering similar information to Page Visibility, like window.onfocus and window.onblur, is already available today and Page Visibility doesn't increase the privacy concern significantly than it already is today, we recommend not making any privacy features to the spec.


b.       Taking Page Visibility to First Public Working Draft

According to the schedule that we outlined in the Charter, this spec is expected to reach FPWD by end of May. Considering the Page Visibility spec is now at a stable state, we recommend publishing it as a FWPD. Unless the WG disagrees, we intend to publish this draft on June 2nd as a FPWD.



5.      Feedback and discussion on requestAnimationFrame.

a.       Duplicate callback functions

The spec isn't clear what is the expected behavior when a duplicate callback is called. E.g., requestAnimationFrame(callback1); requestAnimationFrame(callback1); We believe the expected behavior here should be that the duplicate callback is removed from the animation frame request callback list. ISSUE-6 - (duplicate callbacks): Spec needs to clarify expected behavior for duplicate calls of the same callback [Request Animation Frame] is raised.



b.       Taking Page Visibility to First Public Working Draft

According to the schedule that we outlined in the Charter, this spec is expected to reach FPWD by end of May. However, this spec has six open Issues on it. Our recommendation is to take this spec to FWPD on June 2nd and work through the issues prior to entering Last Call. Unless the WG disagrees, we intend to publish this draft on June 2nd as a FPWD.



We had the following action items from this meeting:

1.       Zhiheng Wang: Update requestStart in Resource Timing with the same fix as made to Navigation Timing

2.       Jatinder Mann: Update initiator definitions in Resource Timing

3.       Jatinder Mann: Update Resource Timing to describe the expected behavior with plugins

4.       Cameron McCormack: Update requestAnimationFrame spec to be clear what the expected behavior is around duplicate callbacks



Detailed Notes:



Web Perf Teleconference #34 5/25/2011



IRC log: http://www.w3.org/2011/05/25-webperf-irc


Meeting Minutes: http://www.w3.org/2011/05/25-webperf-minutes.html



Attendees

Present

Jatinder Mann, Nic Jansma, Christian, JamesS, Anne, Zhiheng, TonyG, Cameron, Phillipe, Arvind Jain



Regrets

James Robinson



Scribe

Jatinder Mann



Meeting Chair

Jatinder Mann



Contents

Agenda

1.       Feedback and discussion on Navigation Timing updates.

2.       Feedback and discussion on Resource Timing updates.

3.       Feedback and discussion on User Timing updates.

4.       Feedback and discussion on Page Visibility.

5.       Feedback and discussion on requestAnimationFrame.



Topics

1.       Resource Timing has reached FPWD as of 5/24.

2.       Initiator type updates

3.       Security review of Resource Timing around statistical fingerprinting

4.       Taking Resource Timing to Last Call

5.       Review Proposal to update User Timing

6.       Privacy Concern

7.       Taking Page Visibility to First Public Working Draft

8.       Monotonic clock



Summary of Action Items

ACTION-32 - Update initiator types definitions to include elements that are included in that initiator types. [on Jatinder Mann - due 2011-06-01].

ACTION-33 - Update spec to include a reference to what the expected behavior with plugins [on Jatinder Mann - due 2011-06-01].

ISSUE-6 - (duplicate callbacks): Spec needs to clarify expected behavior for duplicate calls of the same callback [Request Animation Frame]

ACTION-34 - Update Resource Timing spec with the same requestStart fix made in Navigation Timing spec. [on Zhiheng Wang - due 2011-06-01].



--------------------------------------------------------------------------------



Jatinder: Zhiheng, can you summarize the update made to the Navigation Timing spec?

Zhiheng: When we talk about local resources, we implictly include some cases. In the original draft, requestStart includes checking http cache. We removed that. In case the http cache hit, we should include that requestStart, however, if we have a http cache miss, then it doesn't make sense.

Nic: That makes sense, but let us re-read this after the call.

Jatinder: This change should also go to the resource timing processing model?

Zhiheng: Yes, I will update Resource Timing also.

move to agenda 6
Resource Timing has reached FPWD as of 5/24.

Jatinder: Thank you everyone for helping us to get to this point. Per feedback from last week's call and the mailing list, many fixes went the FWPD draft.
... I have closed ACTION-30 Update the Processing Model.
Initiator type updates

Jatinder: Tony has feedback on the definition of initiator types - http://lists.w3.org/Archives/Public/public-web-perf/2011May/0117.html

ACTION Jatinder to Update initiator types definitions to include elements that are included in that initiator types.

<trackbot> Created ACTION-32 - Update initiator types definitions to include elements that are included in that initiator types. [on Jatinder Mann - due 2011-06-01].

We agree to updating CSS initiator type to CSS_SUBRESOURCE.

We agree to combining the frame and subdocument category into subdocument.

Agree to keep XMLHTTPRequest category as is.

Agree to keep SVG category to include all SVG subresources.

Also agree to naming CSS_SUBRESOURCE as CSS, if we are doing so for SVG, for consistency.

Action Jatinder to update spec to include a reference to what the expected behavior with plugins

<trackbot> Created ACTION-33 - Update spec to include a reference to what the expected behavior with plugins [on Jatinder Mann - due 2011-06-01].
Security review of Resource Timing around statistical fingerprinting

Jatinder: The IE team has conducted a security review of the Resource Timing feature and we have not found any significant issues.

Nic: A malicious site today can get to the same information (like is something in the cache) today using timing handles.

Tony: We should evaluate to see if a privacy concern really does exist before we add text that mitigates it. Rather not taint the spec with a privacy concern, if there isn't one.
... Can Microsoft respond to the mailing list with information on their security review (e.g., found no concerns).

Jatinder: Yes.
Taking Resource Timing to Last Call

Jatinder: Now that we have the spec in a very stable state, I recommend we set next Wednesday (6/1/11) as our date to enter Last Call.

Considering we have a few actions items, let's set the Last Call date tentatively for next Wednesday. If we find that we are not targetting that date by end of this week, we can push it out.

move to agenda 7
Review Proposal to update User Timing

Jatinder: Nic had submitted feedback to the current proposal - http://lists.w3.org/Archives/Public/public-web-perf/2011May/0112.html

Tony: I haven't had a chance to read the proposal yet. Can you summarize on the call briefly? I can look at the mail after the call.
... I think we both agree that there should be a link between marks and measures.

Nic: The bigger point with the current spec was the ease of use of the apis from a web developers point of view.
... In the mailing list, there are three examples given of the advantages of the current proposal: Multi-Phase scenarios, Retrieving only marks or measures, Finding the durations of a specific scenario.
... Options can be to add the timestamps of the two marks to getMeasures() in the current draft or go with your proposal and allow for efficient access of just marks/measures (getMarks(), getMeasures(), getMeasureDurations.
... Let's review the proposals further in the mailing list and get feedback from all.

+Cameron

<plh> http://www.w3.org/2011/05/idl.svg
Privacy Concern

Jatinder: We need to close whether or not we feel that sharing the page visibility state is a privacy concern or not. Considering similar information can be found from window.onfocus and window.onblur, I recommend we don't do any additional work here, as Page Visibility doesn't change the existing privacy concern significantly.
Taking Page Visibility to First Public Working Draft

Jatinder: Per the charter, this spec should be at FWPD by end of this month. I feel that the Page Visibility spec is now at a stable state that we can publish it as a FWPD. Let's set next Wednesday (6/1/11) as our date to enter First Public Working Draft.

I will follow up on the mailing list.

move to agenda 8

move to agenda 9

Jatinder: The spec isn't clear what is the expected behavior when a duplicate callback is called. E.g., requestAnimationFrame(callback1); requestAnimationFrame(callback1); We believe the expected behavior here should be that the duplicate callback is removed from the animation frame request callback list.

Cameron: We should do what setTimeout does. I would suppose it calls twice?

Jatinder: It does call twice. But when would you need to call a callback twice for graphics? The spec needs to be clear in any case.

Cameron: Jatinder, can you open an issue for this?

Jatinder: Yes.

We agree to publish both Page Visibility and Timing control for script-based animations as FPWD next week.

We will let the mailing list know of our intention to publish next week. Unless the WG disagrees, we will target the release next week.

Issue: (duplicate callbacks): Spec needs to clarify expected behavior for duplicate calls of the same callback [Request Animation Frame]

<trackbot> Created ISSUE-6 - (duplicate callbacks): Spec needs to clarify expected behavior for duplicate calls of the same callback [Request Animation Frame] ; please complete additional details at http://www.w3.org/2010/webperf/track/issues/6/edit .
Monotonic clock

Nic: As we defined in the Performance Timing specs, we defined the timing as wallclock time at the time of the page load. The timing increases monotonically, with the UTC time format and millisecond precison. We need to provide a queriable time that's comparable with existing time format.

Philippe: How much long would the Last Call period be?

Jatinder: It should match the Navigation Timing period.

Philippe: That was 4 weeks. We can target Resource Timing last call to be from June 2 - June 30