00:37:42 RRSAgent has joined #webperf 00:37:42 logging to http://www.w3.org/2013/11/14-webperf-irc 00:37:44 RRSAgent, make logs world 00:37:44 Zakim has joined #webperf 00:37:46 Zakim, this will be WPWG 00:37:46 I do not see a conference matching that name scheduled within the next hour, trackbot 00:37:47 Meeting: Web Performance Working Group Teleconference 00:37:48 Date: 14 November 2013 00:46:31 plh has joined #webperf 00:48:42 present+ JatinderMann 00:49:02 present+ PanDeng 00:49:48 hi Jatinder 00:49:57 I'm on the podium at the AC right 00:50:06 let me know when you're ready to start 00:50:09 Hi Philippe 00:50:12 Okay, sound's good 00:50:13 and I'll come in the room 00:53:59 We're just waiting for more people to join. So far it's Pan and I. 00:56:34 Pan has joined #webperf 01:00:53 thinker has joined #webperf 01:01:18 present+ thinker 01:04:33 plh3 has joined #webperf 01:04:56 AutomatedTester has joined #webperf 01:07:54 kkubota2 has joined #webperf 01:08:49 Sam_ has joined #webperf 01:09:21 present+ plh3 01:09:32 present+ AutomatedTester 01:09:39 present+ kkubota2 01:09:46 present+ Sam_ 01:15:05 join #webperf 01:16:00 Jatinder Mann 01:16:00 Pan Deng 01:16:42 Lei Xue 01:17:01 Alois has joined #webperf 01:17:04 ?, Tencent 01:17:11 kkubota2, NTT 01:17:22 Mark Nottingham, Akamais 01:17:28 s/ais/ai/ 01:17:40 Renoir Boulanger, W3C 01:17:48 David Burns, Mozilla 01:18:22 Alois Reitbauer 01:18:28 Jason Weber 01:18:44 Sam ?, Foxconn 01:18:56 Arvind Jain 01:19:47 Topic: Prerender 01:20:10 Jatinder: should HTML5 include prerender? 01:20:36 ... feedback is that we should just consider doing it on microformats 01:21:22 ... but it seems worthwhile to have it part of the spec 01:21:34 ... one feedback 01:21:50 ... around if you replace the current browsing context 01:21:59 ... if you loose "replace" you loose such constraint 01:24:53 Jatinder: Based on the bug, this was accepted to be added to HTML5.1. Are we okay with moving to HTML5 or leave it HTML5.1 01:25:41 Plh: We will need to give test cases if we want this put in. Are we okay with just leaving this? 01:25:55 wonsuk has joined #webperf 01:26:38 rniwa has joined #webperf 01:26:45 Arvind: Ilya raised a resource hints proposal on preconnect, preload, prerender 01:27:19 http://lists.w3.org/Archives/Public/public-web-perf/2013Nov/0043.html 01:28:04 Arvind: As we had discussed in the past, we may want to keep some of this as browser optimizations 01:29:04 Jason: Some of these are environment specific optimizations. I'm not sure we want to require browsers to explain all the details. 01:29:23 Arvind: What's preload and preconnect? Are these new? 01:29:37 Jatinder: It's unclear if some of these are just renaming prefetch or something new. 01:29:52 Plh: It might be worthwhile to specify this in the spec so developers know what to expect 01:30:32 Jason: Depending on environment, like if you're on 3G, you may not want to do these optimizations. 01:31:57 Arvind: Ilya just asked questions here, there weren't any recommendations on the number. As Jason mentioned, the number of connections is hard to specify depending on device and enviroment. I recommend we just leave it as is, but if someone can justify having a specific number then we can add it to the them. 01:32:50 Jatinder: Prefetch is already defined and so is prerender. Are we really trying to define a preconnect 01:33:32 Jason: IE already has an internal database where its checking when to do a preconnect. It doesn't make sense to have a developer give this hint. 01:34:19 sho has joined #webperf 01:34:32 ken has joined #webperf 01:34:53 Arvind: in some cases the browser may not get to a resource fast enough, with a hint we can do something sooner. If you take an example of search engine, it can potentially benefit by specifying a preconnect. 01:35:24 kkubota2_ has joined #webperf 01:35:26 Jatinder: But at parse time the browser will encounter the preconnect attribute at the same time as it encounters the URL. 01:35:38 Jason: this may be more useful for the second page. 01:36:24 Arvind: This might be a very light weight version of prerender. 01:37:02 Arvind: We should make sure this that the spec includes this. The registry includes prerender and the spec includes prefetch. 01:37:43 Jason: IE supports preconnect on a heuristics base. I believe its some 80% hit rate of determining which one is going to be preconnected 01:38:10 Jatinder: Are we leaning towards defining preconnect? 01:38:21 plh has changed the topic to: Agenda: http://www.w3.org/wiki/Web_Performance/November2013Meeting 01:38:30 Jason: I would caution beucase the developer may shoot themselves on the foot. 01:39:02 renoirb has joined #webperf 01:39:07 dns-pretetch 01:39:51 arvind has joined #webperf 01:39:55 https://docs.google.com/presentation/d/18zlAdKAxnc51y_kj-6sWLmnjl6TLnaru_WH0LJTjP-o/present#slide=id.g33211238_0_2 01:40:27 bin_lee has joined #webperf 01:42:06 Arvind: Based on Ilya's slides, there is "dns-prefetch", "prefetch", "prerender", "subresource". At least "prerender" and "prefetch" are supported everyone. "subresource" is unnecessary 01:44:31 Jatinder: I don't think there is any web developer value in giving the specifics on when the browser prerenders. The goal is to have the developer give the web browser a hint. 01:44:47 Arvind: I think we should wait and see if others have more concrete requirements. 01:45:20 Arvind: We should decide on whether or not we should define more states. 01:45:37 Arvind: Looks like some of us aren't happy in defining too many more. 01:47:28 Jason: As of IE11, we support the dns-prefetch tag. 01:48:38 values 01:48:42 plh3 has joined #webperf 01:48:47 http://microformats.org/wiki/existing-rel-values 01:49:44 Sam__ has joined #webperf 01:49:59 Arvind: Looks like we currently have prefetch in the HTML5 spec, prerender and dns-prefetch is in the registry. 01:50:45 ...I think it makes sense to bring in preconnect if dns-prefetch is there. dns-prefetch is the lowest cost, preconnect is a bit more work where we're opening the connection, prefetch will download the resource end to end, and prerender navigates to the page. Seems like it makes sense. 01:52:15 Jatinder: We should discuss with HTML5 WG to include dns-prefetch and prerender. 01:52:23 Arvind: We should discuss all four with the HTML WG. 01:52:47 ACTION Jatinder include prerender, dns-prefetch in HTML5 spec and consider preconnect as well 01:52:47 Created ACTION-112 - Include prerender, dns-prefetch in html5 spec and consider preconnect as well [on Jatinder Mann - due 2013-11-21]. 01:53:14 Jatinder: That's all of our open items. Does anyone else have any other questions? 01:54:03 thinker: I worry if prerender can be used for denial of service type attacks 01:55:15 Arvind: The page can always do a DoS attack. You can always just add the second frame as an iframe already. That will accomplish the same thing. 01:55:41 thinker: I think we should put same origin restrictions. 01:56:32 Arvind: Most of the current use cases are for cross-origins, e.g., a search engine would use the cross-origin prerenders. Both Microsoft and Google are using this in their search engines. I don't think this creates any new surface area because you can already do this. 01:57:21 Jason: There are two parts of this privacy and security. There isn't a new attack vector here just as Arvind mentions. The second problem is using up user's resources by prerendering excessively. I think that's up to the User Agent to be smart 01:58:15 ...about how it prerenders. Chrome and IE both limit the prerenders. 01:58:44 Topic: Beacon 01:59:01 Arvind: We should probably start by talking about the goals of beacon and what isn't already solved by XHR. 02:00:09 Jason: What I'm most excited about beacon is asynchronously sending data when its convienent. Today sites are using XHR by blocking the site's unload to send the data. 02:00:50 ...This is super ugly because it destroys power and perf. The browser internally can try to do optimizations, but it has to do continue doing work in the background. 02:02:03 Jatinder: I would also mention that it really slows down the navigation of the next page. And there is nothing the next page can do. 02:02:34 Daniel_Austin has joined #webperf 02:02:50 Alois: What many people are doing is abusing the img element to send the data, or a sync XHR to really guarantee sending the data. The problem that beacon should solve is sending the data reliably without blocking the page. 02:03:11 Arvind: I agree that XHR doesn't solve this problem and beacon can solve this and is sufficiently different. 02:04:06 Arvind: I agree with the use case of reporting statistics without blocking the page. The use cases that I don't agree with are the battery usage or getting data. 02:05:08 ...There was some suggestion that if you want to batch sending data, we may want to develop a resource batching mechanism that XHR can benefit from. 02:06:13 jeroskim has joined #webperf 02:06:31 Alois: I feel like a lot was brought into the spec, like the battery case and sending a lot of background data. I think we should scope. 02:07:50 Jatinder: Phillipe raised that some people were interested in abusing to use this send large amounts of data. 02:08:42 Arvind: Let's start by talking about the size limitations. 02:09:51 Arvind: Fixed values may look silly in the future. 02:09:59 Jatinder: Does XHR have a limit? 02:10:03 Arvind: No. 02:10:22 Jatinder: But XHR doesn't live after the page has gone away. But beacon can survive. 02:11:24 plh has joined #webperf 02:11:36 Arvind: 10K is too small. 02:11:42 q+ Daniel_Austin 02:12:03 Yudong has joined #webperf 02:13:09 Arvind: Uploading 10GBs will cost you money on your mobile page. So I see a point here. 02:14:47 Arvind: The current solution of spinning is the worse case, as it blocks the unload and you can send as much data as you want. 02:15:35 hayato_ has joined #webperf 02:15:41 Alois: We can also not include this in the spec, but the browser fails silently. 02:16:24 Plh: I don't think we should put a limit in the spec, but should be allow the ability to query data. 02:18:33 Daniel: The upload speeds are slower than download speed. Paypal are a serial XHR abuser. What we've found is that the omniture data is lost. The third point is that we've seen in the past serious abuse where we did not specify limits. Iniitally there weren't any limits on cookie data and people were sending 65K data. UAs started adding arbirtary limits on cookies. We have lost a lot of money as this, because some of our users weren't able to send. 02:19:09 ...I think we should specify a limit. I just checked how much 25K with 6 different XHRs. Let's set a limit but keep it a rational limit. 02:19:33 Arvind: Should the limit be applied at a page level or function level? 02:20:30 Daniel: It should be on a page level. We make multiple calls to omniture. Maybe some of the service worker framework some of this can be used. 02:20:51 Arvind: What about a way to query? 02:20:58 Plh: I don't think it was a good idea afterall. 02:21:03 Jason: Agreed. 02:21:06 Daniel: Agreed. 02:22:56 Alois: What about single page applications? After 20 minutes you can't send any more data. 02:23:59 Daniel: We should set the limit to kilobytes rather than megabytes, especially from a mobile operator point of view. 02:26:12 Jason: We are developing a general purpose platform. We should be careful to set limits. 02:26:29 Jatinder: We have to keep in mind that we want to keep adoption of this API and have people move away from XHR. 02:27:19 Arvind: Partical example. In Google we track clicks using ping when people are clicking on links. Even minor amounts of data loss, you may not use it. 02:29:17 ken has joined #webperf 02:29:46 Daniel: I want my developers to use good practices, but real large scale companies can easily abuse this. I can commonly see marketing folks add yet another analytics data they want to send up. If managing bandwidth should be up to us. 02:30:22 Jatinder: Arvind mentioned whether this should be limited to unload or else. I think this should be a general purpose async method that can be called at any time in the page. 02:30:46 Alois: We have found that data is sent at many times in the page, though unload is most common. I think we should be sent at any time. 02:30:51 Arvind: I agree as well. 02:31:09 Arvind: I don't think we should add any batching details in the spec about battery life. 02:31:42 Jason: I think when you send the beacon, the UA adds the beacon to a queue to send as soon as it can asynchronously send. It should be lower priority than other items. 02:32:15 Arvind: I agree with that. I think the spec should remove the battery life use cases. 02:32:41 ACTION Jatinder update beacon use cases to just be the asynchronous data sending case 02:32:41 Created ACTION-113 - Update beacon use cases to just be the asynchronous data sending case [on Jatinder Mann - due 2013-11-21]. 02:33:13 Arvind: Let's talk about retry. XHRs don't retry right? 02:33:25 Alois: Yep, they just return a failure code, doesn't retry. 02:34:27 Arvind: I think we all agree that we shouldn't return a return code. 02:34:33 Arvind: What are the retry semantics? 02:35:43 Jason: We should leave this to the quality of implementation. 02:35:53 Arvind: The mechanism has to be robust to actually use it. 02:37:52 Alois: The browser may crash not an issue, the server may not be able to accept that's okay too. What about when there is no internet connection. 02:40:01 Alois: I think after 10 minutes the data is useless anyway. Some marketing folks may want to hold data longer. 02:40:35 Jason: I recommend we leave the text quite general and let the user agent may try best effort while maintaining privacy and security. 02:40:51 Arvind: We may want to add examples in the notes. 02:43:36 Daniel: I just checked what our paypal beacon does on my mobile device. It is 26K. It's using Google Analytics and Omniture. 02:44:03 Daniel: We will just not use beacon if it has 10K limit. 02:47:00 Jason: Let me give an example of data URI. Initially it has a 32k limit. We were spec compliant it was great. But developers were sending larger data URI and IE was failing. Now we have a larger limit and sites work. I don't think we should add any limits. Let the browser set the limit. 02:48:19 Arvind: We have closed on a few issues. The beacon should have no limit. The spec shouldn't specify retry logic, but we may consider adding a note in the future. The spec should remove batching logic. 02:49:31 Arvind: I also don't think we should include get. This adds complexity. Its not the common use case. 02:49:34 taocai has joined #webperf 02:49:52 Arvind: I think POST should be the only method. 02:50:37 Alois: I think we should limit to POST as well. 02:50:53 Jatinder: Let's solve the problem we intended to solve. Let's only stick with POST. 02:51:07 ACTION Jatinder Update beacon spec to have no limits, no retry logic, no batching, POST is the only method. 02:51:07 Created ACTION-114 - Update beacon spec to have no limits, no retry logic, no batching, post is the only method. [on Jatinder Mann - due 2013-11-21]. 02:51:59 Daniel: I just checked, and Microsoft.com uses 22KB beacon. 02:52:29 Daniel: Best effort felt like the best security and privacy method. 02:53:50 Suggestion: How about allowing HEAD too, backend might not want to have to create a full document. 02:53:54 myakura has joined #webperf 02:54:18 Arvind: There can be DNS failure, connect failure, server failure. What should you try for these? 02:55:53 Forget about it, sending state update using only URL would not be sufficient. 02:56:10 Arvind: For server busy, I may want to try once or twice right away. We have done some data analysis on this where we found that a single retry significantly incraeses reliability (e.g., if you have a 1% failure rate and you retry once, you'll have a 0.5% impact). 02:56:25 Arvind: I think a random retry for all of these failures may be worthwhile. 02:57:11 Daniel: I know some data carriers block uploads while you're on the call. So it blocks that. 03:14:53 plh3 has joined #webperf 03:15:12 ACTION Arvind Can beacon response set a cookie and if so, is it treated as a first or third party cookie write 03:15:12 Created ACTION-115 - Can beacon response set a cookie and if so, is it treated as a first or third party cookie write [on Arvind Jain - due 2013-11-21]. 03:18:41 ito has joined #webperf 03:23:37 aizu has joined #webperf 03:24:24 a12u has joined #webperf 03:24:27 Alois has joined #webperf 03:26:01 Topic: Resource Priorities 03:26:49 https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourcePriorities/Overview.html 03:27:30 taocai has joined #webperf 03:27:53 rniwa has joined #webperf 03:28:30 adding a link to the Serviceworker proposal to the notes - of possible interest for the beacon discussion: https://github.com/slightlyoff/ServiceWorker/blob/master/explainer.md 03:32:01 joshpeek has joined #webperf 03:33:51 Alois: If you have a postpone on the background image, we don't know that the element is visible yet until we do styling. 03:33:52 ken has joined #webperf 03:34:49 plh has joined #webperf 03:35:14 Jason: IE doesn't even download the resources from CSS until the formatting is done. 03:36:50 sho has joined #webperf 03:37:23 Jason: I think we should remove the postpone CSS property as the browser will already do this work. 03:38:23 rniwa_ has joined #webperf 03:38:28 Anna: In many cases, its hard to know when the image will be in the page. 03:41:40 s/Anna/Anne/ 03:44:00 masatakayakura has joined #webperf 03:52:26 johnny___ has joined #webperf 03:55:14 Jason: Seems like there is agreement that there is a need for lazyload / postpone, but there may be some confusion in the spec. 03:55:19 Anne: I think I agree with that. 03:58:56 Jatinder: Looks like we need to remove the CSS property. 03:59:08 preload none on video http://www.w3schools.com/tags/att_video_preload.asp 04:00:19 junil has joined #webperf 04:00:24 Jason: I think we should scope this to lazyload and then consider adding postpone later on in an Level 2 based on feedback. 04:01:11 Anne: I think we should consider starting with lazyload. For example, the user agent could interpret lazyload to mean postpone based on data. 04:02:07 https://github.com/slightlyoff/ServiceWorker/blob/master/explainer.md 04:06:41 I can be summoned by meme... 04:06:42 AutomatedTester has joined #webperf 04:06:45 ;-) 04:14:55 Off to lunch break. 04:15:15 Zakim has left #webperf 04:15:35 ken has joined #webperf 04:37:51 ito has left #webperf 04:48:52 johnny has joined #webperf 05:11:06 johnny__ has joined #webperf 05:13:08 Alois has joined #webperf 05:13:45 simonste_ has joined #webperf 05:14:47 johnny has joined #webperf 05:17:24 Sam has joined #webperf 05:18:23 AutomatedTester has joined #webperf 05:18:51 annevk has joined #webperf 05:18:54 Hello 05:19:02 \o/ 05:19:37 JatinderMann has joined #webperf 05:19:44 wb 05:19:58 JatinderMann_ has joined #WebPerf 05:20:24 Topic: Page Visibility 05:21:51 plh has joined #webperf 05:22:34 junil has joined #webperf 05:25:56 Pan has joined #webperf 05:26:02 danielkim has joined #webperf 05:26:02 a12u has joined #webperf 05:26:09 ken has joined #webperf 05:26:35 aizu has joined #webperf 05:27:18 myakura has joined #webperf 05:28:26 The WebDriver spec had a bash at attempting to define visibility: http://www.w3.org/TR/webdriver/#determining-visibility 05:28:29 Jatinder: We need to define visibility in Level 2 spec. Is it fine to tie visibility to the viewport or the users agent's intrepretation of the viewport. 05:29:04 Jason: We should tie it to the viewport, which is what the user sees. Tying it to the user agent's internal intrepretation just seems to add complexity. 05:29:49 pmsangal has joined #webperf 05:31:36 Arvind: I think we need to cover give more details on the definition, including display:none. 05:32:55 ken_ has joined #webperf 05:33:04 Hi. Is there a phone bridge, for TPAC, that I can dial into? 05:33:05 Daniel_Austin has joined #webperf 05:34:01 rniwa has joined #webperf 05:35:21 Simon: We need to define element visibility for Web Driver. 05:37:13 arvind has joined #webperf 05:37:15 http://lists.w3.org/Archives/Public/public-web-perf/2013Oct/0031.html 05:37:28 pmsangal, yes, there is 05:37:51 zakim, room for 4 for 240 minutes? 05:37:54 Zakim has joined #webperf 05:37:59 zakim, room for 4 for 240 minutes? 05:38:00 ok, plh; conference Team_(webperf)05:37Z scheduled with code 26631 (CONF1) for 240 minutes until 0937Z 05:38:20 zakim, call wuzhou-middle 05:38:20 I am sorry, plh; I do not know a number for wuzhou-middle 05:38:27 zakim, call wuzhou-_iddle 05:38:27 I am sorry, plh; I do not know a number for wuzhou-_iddle 05:38:31 zakim, call wuzhou_iddle 05:38:31 I am sorry, plh; I do not know a number for wuzhou_iddle 05:38:37 zakim, call wuzhou_middle 05:38:37 ok, plh; the call is being made 05:38:38 Team_(webperf)05:37Z has now started 05:38:39 +Wuzhou_middle 05:39:00 zakim, passcode? 05:39:00 the conference code is 26631 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), plh 05:39:13 pmsangal, we're on the bridge now 05:39:23 thanks, I'll dial in 05:40:02 + +1.617.294.aaaa 05:40:04 - +1.617.294.aaaa 05:40:04 + +1.617.294.aaaa 05:40:42 Simon: We should really call our spec as displayability, instead of visibility. 05:40:45 - +1.617.294.aaaa 05:42:13 + +1.617.294.aabb 05:42:15 - +1.617.294.aabb 05:42:15 + +1.617.294.aabb 05:42:23 Jason: From the advertising point of view, they want proper element visibilty that gives them with high confidence that the ad is on or off screen. 05:43:07 ok I'm in, but I don't hear anything. Is the line muted? 05:43:45 nope, it's not muted :( 05:43:48 -Wuzhou_middle 05:43:50 I'm finding this flash discussion really interesting. 05:43:54 oops 05:43:58 we got dropped 05:44:07 zakim, call wuzhou_middle 05:44:07 ok, plh; the call is being made 05:44:09 +Wuzhou_middle 05:44:30 Jason: Today, advertisers use many techniques to determine visibility, including flash. 05:44:33 zakim, drop wuzhou 05:44:33 Wuzhou_middle is being disconnected 05:44:34 -Wuzhou_middle 05:44:37 zakim, call wuzhou_middle 05:44:37 ok, plh; the call is being made 05:44:39 +Wuzhou_middle 05:45:22 zakim, mute aabb 05:45:22 +1.617.294.aabb should now be muted 05:45:23 Jason: We can probably define it as a layout level displayable, but I don't know if I'd call it visibility. 05:45:47 pmsangal, I muted you since we were able to hear you 05:46:12 Sorry about that. I'm in now, thx 05:46:21 zakim, aabb is pmsangal 05:46:22 +pmsangal; got it 05:46:47 it's a big room and not everybody is sitting next to the polycom :( 05:47:17 Arvind: I think element visibility is harder. I rather think about iframe visibility. 05:47:40 Anne: Isn't it the same issue as element visibility? 05:47:53 plh: np, I'll try for sometime. If I can't make out what's happening, over the phone, I'll drop off and attend the next TPAC in person :) 05:48:26 rniwa has joined #webperf 05:50:02 Jason: From a display point of view, it's the same problem. 05:51:13 igarashi has joined #webperf 05:52:11 igarashi has left #webperf 05:54:39 One other thing to keep in mind: http://dev.w3.org/csswg/cssom-view/#extensions-to-the-document-interface 05:55:43 The intention here is that "getElementFromPoint" would return the top-most "visible" element. With a slightly better nuancing. 05:55:51 sho has joined #webperf 05:56:42 simonstewart: it returns the hittable element 05:56:52 Right 05:57:13 s/"visbible" element/"hittable" element/ 05:57:20 kkubota2 has joined #webperf 05:58:30 Jatinder: For Page Visibility L1, when we say you are hidden, we are certain that you are hidden. When we say that your are visible, you may or may not be visible. 05:59:10 Jatinder: Should we apply the same principal to the L2 spec? 06:00:40 JatinderMann_: that definition might well work for WebDriver. We already have a fairly loose definition of visibility. 06:00:51 rniwa has joined #webperf 06:00:53 Jason: You can give layout information like your width and display, but that's not necessarily what the display sees 06:01:06 myakura has joined #webperf 06:01:30 dennisdmac_ has joined #webperf 06:02:05 Anne: We should follow up with CSS folks and see if they want to support this. 06:02:33 Jason: We can possibly provide the layout properties and let them know if there is a transform applied. 06:04:35 Jason: If you have an Ad in the center of the page. If you have the CSS transform to 1px, there is no way to make sure that the Ad is no visible, because that's happening on the GPU. So we can give layout coordinates and a boolean api that lets them know if there are css transforms or other graphics techniques. This could be enough solution to solve the advertiser scenario. 06:04:47 Simon: The Web Driver could also use that potentially. 06:05:29 mz-modeltaxi has joined #webperf 06:05:49 taocai has joined #webperf 06:07:25 Jatinder: Is there a scenario where we want the current Page Visibility L2 spec where visibility is tied to the document and not the top level document. 06:09:22 https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/HighResolutionTime2/Overview.html 06:09:23 aizu has joined #webperf 06:11:14 Topic: High Resolution Time 06:11:25 Anne: Can we remove the NoInterfaceObject 06:11:26 ? 06:11:49 Jatinder: Yes, I can remove. 06:11:58 Plh: Can we move to Last CAll? 06:12:01 Jatinder: Yes. 06:12:16 Resolved: HRT 2 to Last Call 06:14:07 johnny has joined #webperf 06:14:56 Topic: Navigation Error Logging 06:15:14 Daniel: I prefer having detailed errors, not just the general errors. 06:16:18 Daniel: Today, we have to have many tools to determine error cases, I'm still going to be stuck with getting those errors. I don't think general errors are good enough, we need explicit errors. 06:17:23 ...There were a number of proposals to solve this. We had looked at a bunch of different lists of errors, including POSIX. 06:19:24 ...The POSIX spec doesn't define any of the errors in very specific ways, so different machines give different error numbers. I don't feel these lists are useful. 06:19:46 Jatinder: Does it make sense for us to define a list of errors we want to support in our spec? 06:20:29 ken has joined #webperf 06:24:19 http://lists.w3.org/Archives/Public/public-web-perf/2013Apr/0007.html 06:28:13 Anne: That's why we don't want to share errors in XHR. This topic has come up before many times before, and it's always been shot down. 06:29:10 http://lists.w3.org/Archives/Public/public-web-perf/2013May/0053.html 06:29:31 Anne: You may want to do a security review. 06:31:28 Alois: We may want to ask the security team both whether its a problem to share the detailed and not detailed security information. 06:31:45 http://lists.w3.org/Archives/Public/public-web-perf/2013Apr/0007.html 06:32:17 ACTION Jatinder Do review to see if sharing these network errors is a security or privacy concern 06:32:18 Created ACTION-116 - Do review to see if sharing these network errors is a security or privacy concern [on Jatinder Mann - due 2013-11-21]. 06:33:06 -pmsangal 06:34:47 Mark: There are issues that we need to consider about standarizing a list. How do we handle new errors that have been created. We may want to consider black or whitelisting errors in the registry. 06:35:26 ken has joined #webperf 06:36:55 -Wuzhou_middle 06:36:56 Team_(webperf)05:37Z has ended 06:36:56 Attendees were Wuzhou_middle, +1.617.294.aaaa, +1.617.294.aabb, pmsangal 06:37:55 Mark: Instead of having one field, we may have two fields to make it easier. 06:38:08 Jatinder: We are very open to API surface. 06:39:52 Jatinder: Which one of these errors are we not concerned with? 06:39:53 yahui has joined #webperf 06:40:00 http://lists.w3.org/Archives/Public/public-web-perf/2013Apr/att-0007/WebRequestStatusCodes4.html 06:41:07 pmsangal has joined #webperf 06:41:58 Mark: 200s are fine, a lot of these are fine. Some of these that give more information on the user should be a problem. 06:44:18 johnny_ has joined #webperf 06:48:37 Arvind: Some folks are Google are interested in reporting the errors to a different URL. 06:49:07 Alois: This makes a lot more sense. Because if you're going to see the problem after its fixed, then this API is useful. 06:49:19 Anne: Coordinate with the CSP guys. 06:49:35 Arvind: This would just be like report URI. 06:50:33 rrsagent, this meeting spans midnight 06:51:43 ACTION Arvind add method to allow ability to send to a third party URL using CSP 06:51:43 Created ACTION-117 - Add method to allow ability to send to a third party url using csp [on Arvind Jain - due 2013-11-21]. 06:52:51 wilhelm has joined #webperf 06:53:35 ACTION Mark to review the error list and reduce it down 06:53:36 Created ACTION-118 - Review the error list and reduce it down [on Mark Nottingham - due 2013-11-21]. 06:56:01 Topic: Resource Timing 06:56:17 http://www.w3.org/2013/11/cr-resource-timing.html 06:58:10 AndroUser has joined #webperf 07:02:11 Arvind: We closed "A resource request without a network connection" feedback from James Simonsen. 07:03:14 Jatinder: Resource Timing doesn't include resources that have errors. So closing "Resource request: failure and success? (Andy Davies)" 07:06:01 pmsangal has joined #webperf 07:10:03 Plh: We should include a 404 error code test to see if it is included in the resource timing 07:12:30 myakura has joined #webperf 07:14:29 johnny has joined #webperf 07:15:44 giuseppep has joined #webperf 07:17:04 kimwoonyoung has joined #webperf 07:25:25 cwdoh_ has joined #webperf 07:25:46