[minutes] 20110601 Web Performance WG Teleconference #35

Meeting Summary:



1.      Discussed feedback and updates to the Navigation Timing spec

a.       Reviewed list of remaining issues with Navigation Timing.

Philippe had prepared a list of issues that were raised in the mailing list and may still need to be resolved: http://www.w3.org/2011/06/navigation-timing-issues.html. The WG will review these items to ensure they are closed. From a brief look, it appears that most of the issues have been resolved, save the bfcache test case.



b.       Consider updating spec to be more clear about expected behavior with bfcache

Firefox and Safari implement a bfcache. The spec isn't clear on what the expected behavior should be for browsers that implement a bfcache. This issue had been previously raised in the mailing list, and at that time it was deemed that no action was needed. We have opened ACTION-37 to consider updating Navigation Timing to make it more clear what the expectations here are. Further, we have opened ACTION-38 to update http://w3c-test.org/webperf/tests/approved/test_navigation_type_backforward.htm test case to deal with bfcache if it exists.



c.        Update Navigation Timing to include  a section on vendor prefixes

ACTION-35 Add a Vendor Prefix section to Navigation Timing was opened on Zhiheng to ensure that Navigation Timing covers this information in the same manner as Resource Timing does.



2.      Discussed feedback and updates to the Resource Timing spec

a.       Concerns regarding a future growth potentials

There were concerns that the current performance specifications are not well designed for future growth - adding a new performance measurement API requires adding more APIs. E.g., if one were to add a graphics performance API, currently it will have to compete in the same namespace as Navigation, User and Resource Timing. James Simonsen feels strongly that all performance specification can be defined with a single API. Extending this API to include other types of measurements will be easier. James will provide a proposal by end of this week for review by the WG.



b.       Exposing additional sensitive data in Resource Timing

There was an ask to expose additional sensitive data like HTTP responses for all resources. The proposal is to expose this information to all scripts, regardless of their origin, that originate from the same domain as the current document or block cross-domain scripts added to a page. The current web convention is to treat cross-domain scripts that are added via the <script> tag with the same level of access as a script added on the page. Further, giving HTTP response code type of information to even the same origin scripts may create a fingerprinting security issue. WG members will follow up with their user agent security teams to consider the security implications of this proposal.



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

a.       Considering Page Visibility and Idle state proposals.

We don't see these two specs as competing proposals, but rather as complimentary. Today, developers don't have the information needed to make informed decisions. Information like page visibility, machine idleness (e.g., CPU usage), user idleness (e.g., user interactions with page), and battery life can all help developers create more tailored and efficient application. We are happy with the progress made on the Page Visibility spec. We can re-charter in the future to add Machine Idle and User Idle. Kyle has taken an action item to draft up a proposal for User Idle that can be considered for the next re-charter.


b.       Taking Page Visibility to First Public Working Draft

The First Public Working Draft of this spec is to be published tomorrow, June 2nd.





4.      Feedback and discussion on requestAnimationFrame.

a.       Duplicate callback functions
Agreed we should stick with the convention of calling duplicate callbacks set by setInterval/setTimeout. Considering requestAnimationFrame is meant to be the replacement for setInterval/setTimeout for animations, using the same model here will make it less confusing and easier for web devs to port their code to use the new API. Jatinder will close Issue 6.


b.       FrameRequestCallback interface should be designated as Callback=FunctionOnly

Issue 7 was raised to designated FrameRequestCallback interface as Callback=FunctionOnly. We agreed to not want to allow objects to be registered as callbacks, especially seeing that the API seems to have been designed for function callbacks.


c.        Taking Page Visibility to First Public Working Draft

The First Public Working Draft of this spec is to be published tomorrow, June 2nd.



We had the following action items from this meeting:

1.       Zhiheng Wang: Add a Vendor Prefix section to Navigation Timing (ACTION-35).

2.       Jatinder Mann: Add a Vendor Prefix section to User Timing (ACTION-36).

3.       Zhiheng Wang: Update the Navigation Timing to be clear what the expected behavior with bfcache (ACTION-37).

4.       Karen Anderson: Update http://w3c-test.org/webperf/tests/approved/test_navigation_type_backforward.htm test case to deal with bfcache (ACTION-38).



Detailed Notes:



Web Perf Teleconference #35 6/01/2011



IRC log: http://www.w3.org/2011/06/01-webperf-irc


Meeting Minutes: http://www.w3.org/2011/06/01-webperf-minutes.html



Attendees

Present

Jatinder Mann, Christian, JamesS, Anne, Zhiheng, TonyG, Cameron, Phillipe, Arvind Jain, Jason Weber, Kyle Simpson



Regrets

James Robinson



Scribe

Jatinder Mann



Contents

Agenda

1.       Discuss Navigation Timings CR issues.

2.       Discuss feedback on Resource Timing and taking spec to Last Call.

3.       Discuss feedback on User Timing.

4.       Discuss Page Visibility and IDLE state.

5.       Discuss feedback on requestAnimationFrame.


Summary of Action Items

ACTION-37 - Update the Navigation Timing to be clear what the expected behavior with bfcache. [on Zhiheng Wang - due 2011-06-08].

ACTION-38 - Anderson Update http://w3c-test.org/webperf/tests/approved/test_navigation_type_backforward.htm test case to deal with bfcache. [on Karen Anderson - due 2011-06-08].





--------------------------------------------------------------------------------
Discuss Navigation Timings CR issues.

Jatinder: Philippe has prepared a list of issues that were raised in the mailing list and may still need to be resolved: http://www.w3.org/2011/06/navigation-timing-issues.html
... Which of these are outstanding? Per Zhiheng's response, it appears that only the http://w3c-test.org/webperf/tests/approved/test_navigation_type_backforward.htm test case needs to be updated to deal with bfcache (we concluded that values shouldn't change due to bfcache).

Zhiheng: That appears to be the only issue so far.

Philippe: It would be best if we can respond on the mailing list if these issues have been resolved.

Jatinder: Who would like to update the http://w3c-test.org/webperf/tests/approved/test_navigation_type_backforward.htm?

Zhiheng: We can do so by using the onunloader handler.

Tony: Have we decided what the correct behavior here should be?

Zhiheng: We had discussed on the mailing list that we don't want to make a change here to reduce confusion.

http://lists.w3.org/Archives/Public/public-web-perf/2011Mar/0110.html

JamesS: Don't we risk the page reporting the data twice here?

Anne: I had a question about bfcache. Do you get domready events?

Kyle: It treats the page as being hidden and brings it back.

Anne: All browsers?

Kyle: Just Firefox.

Anne: On the first page load, if you dumped data to the server. If we go back and forward, would more stuff be added to the bfcache?
... on a timer.
... It should at least be marked in the data that this came from the back forward.

<Christian> anne=anne sullivan?

<simonjam> yes

ACTION Update the Navigation Timing to be clear what the expected behavior with bfcache on Zhiheng

<trackbot> Sorry, couldn't find user - Update

ACTION to Zhiheng to Update the Navigation Timing to be clear what the expected behavior with bfcache

<trackbot> Sorry, couldn't find user - to
Discuss feedback on Resource Timing and taking spec to Last Call.

Jatinder: Per last week's discussion, our goal is to enter Last Call for Resource Timing as soon as we can. I have added Section 4.6 Vendor Prefix to respond to Sigborn's feedback on the mailing list, and have opened ACTION 35 and 36 to make similar changes to Navigation Timing and User Timing. Are there any other issues that need to be responded to prior to entering Last Call?

James: We need to discuss future direction. We need to do a better job with these APIs. We should treat the timing information similar to the DOM, have one API and build from it.

Arvind: Tony, what about the Navigation Timing API? Are your concerns only specific to Resource Timing?

James: For example, you tried to create a new performance timing API for webGL, we would have to create new APIs.

James to have an updated unified proposal API by end of the week.

Arvind: We shouldn't go into Last Call for a week or two.

Jatinder: Agree that we shouldn't go into Last Call until we have consensus.

Kyle: I want to include the HTTP response code.

Jatinder: I believe this was discussed on the mailing list prior - does anyone remember why we didn't make this change?

James: I believe it was because of privacy concerns that we didn't include this.

Kyle: Should we allow third party scripts that are added via <script> to have the same level of access as a script added on the page.

Jatinder: The convention on the web is to treat third party scripts added to the page, as a script on the page.

Kyle: Want to include HTTP response code. We can only provide this information to same-origin and not cross-origin.

Jatinder: Biggest concern with HTTP response code is that they can create finger printing attacks.

Discuss Page Visibility and IDLE state

Jatinder: There has been some heated debates on the mailing list whether we should use Page Visibility or IDLE states in order to help web developers write CPU and power efficient applications. We all want to provide the right tools to let web developers create efficient applications, we need to agree on the means. Let's use the teleconference forum to discuss both proposals.

Jason: I don't see these as competing proposals, but rather as complimentary. Today developers don't have the information to informed decisions. For example, a developer doesn't understand when a browser is minified; page visibility can help here. As I been looking at the threads for a few months now, I can see that there have been additional APIs that can help give more information. For example, the cpu idle state of the machine and the machine b
... up is another interesting information that will be useful for web developers.
... I recommend we continue with the current charter and finish these specs. We can continue to add more specs in the charter.

Arvind: I agree with what Jason just has said.

Kyle: What does Page Visibility give that IDLE doesn't?

Arvind: I need clarity on the multi-tasking/multi-monitor scenario. If we don't provide a Page Visibility API and only provide an IDLE state API, how will a web developer know whether the user is definitively not viewing a page? If a user has a browser and another application opened and visible at the same time, but is only interacting with the application, the IDLE state API may change the behavior of a page, even though it shouldn't.

Jason: If the page goes into a background tab, the page may want to bring the resources down to zero.

Kyle: Fair enough that was a performance scenario.

Cameron: IDLE doesn't give the scenario where the page is visible but is not being interacted with.

Arvind: IDLE wouldn't give the prerendered scenario either.

Kyle: That's definitely a scenario I haven't considered before.

Jason: We had re-chartered to specifically include Page Visibility into the Web Performance WG and we like where Page Visibility is going. We can re-charter to add machine idle and user idle in the future. Kyle, if you can draft up a proposal for user idle, we can consider it.

Kyle: Agreed.
Discuss feedback on requestAnimationFrame.

Jatinder: I raised Issue-7 FrameRequestCallback interface should be designated as Callback=FunctionOnly. We may not want to allow objects to be registered as callbacks, especially seeing that the API seems to have been designed for function callbacks.
... We are planning on taking this spec to first public draft tomorrow. Are there any objections?

No objections.

<plh> http://www.w3.org/TR/2011/WD-animation-timing-20110602/

<heycam> plh, cool, I'll update the version in hg with the new short name