07:58:50 RRSAgent has joined #webperf 07:58:50 logging to http://www.w3.org/2016/09/22-webperf-irc 07:58:56 Zakim has joined #webperf 07:59:28 zakim, this is TPAC Web Performance WG meeting 07:59:28 got it, xiaoqian 08:01:06 cristi has joined #webperf 08:07:11 yoav has joined #webperf 08:11:21 meeting: TPAC Web Performance WG meeting 08:11:26 chair: igrigorik 08:11:35 present+ igrigorik, toddreisteck, yoav, nolanlawson, rniwa, plh, keiji, shubhie, xiaoqian, Nathan_Schloss 08:12:34 bz has joined #webperf 08:13:00 scribe: xiaoqian 08:14:32 Agenda: https://docs.google.com/document/d/1U2DfWlToLlDoJyGvDZytM6VM2p67qisuCOfgnWIclzw/edit# 08:17:26 present+ annevk 08:19:55 kbx has joined #webperf 08:20:19 plh has joined #webperf 08:20:22 rniwa has joined #webperf 08:20:28 n8s has joined #webperf 08:20:34 annevk has joined #webperf 08:21:10 Topic: inconsistent implementation of Timing-Allow-Origin 08:21:26 GuidoGrassel has joined #webperf 08:21:46 shubhiepanicker has joined #webperf 08:22:14 igrigorik: https://github.com/w3c/resource-timing/issues/62#issuecomment-234623339 -> background 08:22:44 ... it doesn't allow start 08:23:01 annevk: yep, you can't use start 08:24:17 igrigorik: we did some test. some sites use workers. that's why we need that. 08:24:52 ... do we need to introduce syntax? 08:25:25 ... test to allow two origins, Chrome doesn't work. 08:25:52 ... Firefox combine both headers with comma and then time origins don't work 08:26:38 ... should we change the spec definition? 08:26:52 yoav: We need to change all implementation in that way 08:27:02 annevk: That's going to happen 08:28:27 igrigorik: In RT, uses the origin-list-or-null definition from rfc6454 08:28:36 annevk: That's fine 08:33:32 bkardell_ has joined #WebPerf 08:33:54 annevk: suggest you should discuss with WebAppSec folks about this solution 08:34:26 RESOLUTION: Update TAO to #( origin-or-null / wildcard ) 08:35:02 annevk: the other thing about TAO is you don't require that... worth checking 08:35:30 ... we should integrate with Fetch to make sure that works 08:36:03 igrigorik: right, maybe Level 2 stuffs 08:36:19 Topic: Beacon 08:36:24 The other thing about TAO was about redirect handling, but it seems the semantics do match CORS there 08:39:40 igrigorik: if we do post, your Fetch may stop twice 08:40:52 GuidoGrassel has joined #webperf 08:42:25 ... when we define Beacon, we have note for reasonable size 08:43:16 olivexu has joined #webperf 08:43:21 ... we can do streams, if the environment obj goes away 08:43:52 toddreifsteck: if the stream have not finish when the environment obj ends, that's the problem 08:44:10 igrigorik: should we consider not allow stream 08:44:37 annevk: sounds ok, some one needs to define the process model 08:45:17 s/Topic: Beacon/Topic: Beacon integration with Fetch API 08:46:04 toddreifsteck: if we get this to work, for old browsers, there should be a fallback 08:46:52 annevk: we haven't added it to the spec, depends on the GC 08:49:21 igrigorik: if we are going to throw the error 08:49:32 annevk: type error perhaps 08:50:00 ... should be able to expose more detail 08:50:33 igrigorik: would be good to have more detail from fetch 08:51:41 toddreifsteck: RT is some browsers has problems on this 08:52:29 igrigorik: it might help to get CORS information 08:52:52 ... for same origins, we don't open more connection 08:53:14 annevk: if there are connection error, just expose one bit 08:54:10 igrigorik: if you using same orgins, you already open the DNS 08:57:00 toddreifsteck: do we need to add some to fetch to get information for the body? 08:59:43 annevk: that design was wrong, only the first argument make sense to me 09:02:25 yoav: Do we want a separate flag for Beacon? 09:02:35 [yes] 09:03:49 rniwa: What's the timing for send beacon? 09:04:30 igrigorik: when page is closed, all requests must be sent 09:09:14 annevk: Should the flag tie to keep-alive? 09:11:41 igrigorik: we don't want to over specify it, in v1 keep it simple and allow UA to implement it 09:14:02 rniwa: keep-alive might involve delay 09:14:48 annevk: it don't allow initiating new Fetch 09:16:01 ... so should be a problem 09:18:23 toddreifsteck: we have keep-alive as a short term flag we should add to 09:19:53 ... does the developers use coalescing? 09:20:10 n8s: perhaps, once it's enable 09:21:20 toddreifsteck: we should keep on the discussion for coalescing 09:24:44 GuidoGrassel has joined #webperf 09:25:20 RRSAgent, make minutes 09:25:20 I have made the request to generate http://www.w3.org/2016/09/22-webperf-minutes.html xiaoqian 09:25:32 RRSAgent, make log public 09:27:22 RRSAgent, drop minutes 09:27:22 I'm logging. I don't understand 'drop minutes', xiaoqian. Try /msg RRSAgent help 09:28:23 yoav has joined #webperf 09:29:20 RRSAgent, make minutes 09:29:20 I have made the request to generate http://www.w3.org/2016/09/22-webperf-minutes.html xiaoqian 09:39:27 yoav has joined #webperf 09:42:19 present+ guido_grassel 09:43:16 present+ bz 09:52:17 yoav has joined #webperf 09:53:49 n8s has joined #webperf 09:55:09 present+ paul 09:55:15 Topic: Mechanism to translate timestamps between globals 09:55:40 https://github.com/w3c/hr-time/pull/29 background 09:57:39 igrigorik: we exposed HR time, which is useful for many use cases 09:58:15 ... we also have time origin, for worker, it's fine as it has its own time origin 09:58:46 ... but you will get difference value if you have many workers along the timeline 09:59:37 ... question is how to translate the time stamp between workers 09:59:57 kbx has joined #webperf 10:01:30 toddreifsteck: there's a lot of trade off 10:01:54 igrigorik: opt1 -> see fig. 10:02:52 ... we need a timestamp to tell you what is the zero time 10:03:57 bz: date time doesn't affect date now, when it change timezone 10:04:51 igrigorik: is it a problem to expose the whole timeline? 10:05:19 rniwa: might be a problem 10:05:56 ... you need to set it as a top level changes 10:06:12 toddreifsteck: why/ 10:07:18 rniwa: most UA isolate iframes, when the monotonic clock starts, it will... 10:08:11 igrigorik: opt2. use a pick obj, and get a timeOrigin back 10:08:27 ... then figure out what's the offset 10:09:06 n8s: when you post message in the SW, if the window is not ready 10:09:19 Byungjin has joined #webperf 10:09:25 bz: the SW will set zero offset before sending 10:09:59 ... it can still send the message 10:10:26 ... what will the SW do about the global offset? 10:10:44 n8s: the window can separately upload the data 10:11:04 toddreifsteck: windows can collaborate things 10:12:24 olivexu has joined #webperf 10:12:43 taekyu has joined #webperf 10:13:07 igrigorik: what we need is a HR timestamp to coordinate 10:13:56 yoav: if we expose the timestamp, can we reset and start over for privacy need? 10:15:05 bz: global timeline, is it cross origin? 10:16:31 toddreifsteck: UAs use fingerprints 10:17:33 bz: to implement, browsers start a monotonic clock 10:17:58 ... create timestamp 10:18:22 yoav: if the users have change the clock between the stamps were created 10:19:01 ... the offset between those clock 10:19:23 toddreifsteck: is it an important leap but? 10:19:51 igrigorik: we don't need to visit it twice 10:20:11 ... the zero of the global clock 10:20:22 rniwa: in the current world, you can reset it 10:20:39 yoav: no... cross site, SW 10:21:27 rniwa: iframes for the same origin, you don't expose it, right? 10:21:46 igrigorik: how do you implement it? 10:21:49 rniwa: hash map? 10:22:14 toddreifsteck: fingerprint, is it reusable? 10:22:46 rniwa: it's trackable 10:24:28 bz: we have two clocks which is in-sync 10:25:14 ... it's unreliable if the clocks start drifting 10:25:32 toddreifsteck: currently it's visible to the pages 10:27:46 bz: for the prospect of browser, only system clocks available 10:29:18 rniwa: there may be a timing attack 10:29:39 igrigorik: some browser will limit the HR time to ms 10:30:32 toddreifsteck: you can make it close to HRtime now 10:31:05 yoav: we are not 100% sure there will be privacy concern 10:31:44 n8s: if there's time attack, perhaps you want less data 10:32:29 toddreifsteck: this explosion doesn't add anything to the concern of time attack 10:33:51 igrigorik: if you already in the top level, you can grab and send 10:34:21 rniwa: you do need other origin to cooperate with you 10:34:59 igrigorik: I'm not convince there will be privacy concern 10:35:47 ... we expose something, we are not sure it's bad or not 10:36:44 rniwa: how do you want to coordinate the time between the different processes? 10:37:02 bz: each process will have its own zero time and offset 10:37:26 yoav: can they be sync once in a while? 10:37:33 bz: donno 10:38:54 rniwa: if one of the monotonic clock drifts, how do you collaborate? 10:39:27 yoav: correct your measurement once drifting 10:40:01 toddreifsteck: Is it actually a thing that happen significantly in reality? 10:40:19 ... we can "could" 10:40:33 yoav: when you reset your computer 10:40:48 s/we can "could"/we say "could" 10:41:01 s/significantly/significantly often 10:41:47 rniwa: I don't have more information, only a concern 10:42:10 toddreifsteck: in windows, resetting only happen in a long period of time 10:42:54 igrigorik: does this give us any improvement to expose the drift? 10:43:39 yoav: you will be able to correct the drift only no process if holding the obj 10:45:11 ... if you correct the drift, all the translations will excuse 10:46:38 rniwa: what if you kept a bunch of timestamps, how will you translate them? 10:47:29 bz: every time you create a time origin... 10:47:49 toddreifsteck: there's a method in windows 10:48:34 igrigorik: we have a global time clock... 10:48:53 bz: it will be heavy performance price 10:49:20 igrigorik: we can't solve it without the support of lower level 10:49:47 bz: they can sync up in some way 10:50:07 ... what's problem are we going to solve with time origin? 10:50:27 ... have a nice API 10:51:45 toddreifsteck: this only help solve fingerprints with tracking 10:52:02 GuidoGrassel has joined #webperf 10:52:46 igrigorik: perhaps we should go to the security team 10:53:17 toddreifsteck: we shouldn't hold the shipping just because the sec team is not sure 10:55:47 ... if everyone just add their offset to the timeline, perhaps is the simplest way 10:56:09 igrigorik: send it in a global time? 10:59:05 toddreifsteck: I have a JS client, your code is running on the client, does it make it easier to grab the info and send it to the cloud? 10:59:20 s/I have/You have 10:59:39 igrigorik: when is the message be pushed? 11:00:32 ... either the sender and receiver can do the translation 11:01:14 ... if receiver do the translation, that will clarify it a bit 11:02:05 rniwa: You don't want to translate the time before sending... 11:02:48 ... if the tracking concern is not an issue 11:03:31 ... you don't have to do anything except sending the data 11:04:11 igrigorik: How does this API work with SPA? 11:07:25 keiji: if there's a new page view 11:08:31 igrigorik: Should be a concept for multiple time origins? 11:09:07 nolanlawson: the platform has the ability to offer performance.now 11:09:25 toddreifsteck: performance.mark works 11:10:14 n8s: marking RT seems be worry 11:10:42 bz: the only thing changes is the final calculation 11:11:16 ... once you allow resetting performance.now 11:14:09 igrigorik: the SPA discussion will affect the above time-origin issue 11:14:54 ... for purpose of translate time, we move forward with that 11:15:13 ... expose an attribute that give you the global time 11:15:50 ... we can close that and also update the privacy discussion 11:16:04 toddreifsteck: and info the sec people we are going to ship it 11:16:19 bz: send some mails to the sec people 11:17:06 shubhiepanicker: yep, continue the SPA discussion, with more use cases 11:17:16 RRSAgent, make mintues 11:17:16 I'm logging. I don't understand 'make mintues', xiaoqian. Try /msg RRSAgent help 11:17:26 RRSAgent, make minutes 11:17:26 I have made the request to generate http://www.w3.org/2016/09/22-webperf-minutes.html xiaoqian 12:03:51 Zakim has left #webperf 12:22:11 Zakim has joined #webperf 12:33:36 bz has joined #webperf 12:40:52 yoav has joined #webperf 12:45:51 kbx has joined #webperf 12:47:26 topic: User-Timing: SYNTAX_ERR exception 12:48:14 https://github.com/w3c/user-timing/issues/1 -> background 12:48:38 n8s has joined #webperf 12:49:34 igrigorik: suggest we freeze the list of attributes on NT1 and move on 12:50:53 toddreifsteck: if you parse a string, that doesn't match anything, that's the case it will throw 12:52:05 Topic: SPA apps and Perf APIs 12:53:23 shubhiepanicker: Developers detect the navigation, loading, ..., by guessing 12:53:51 ... it makes sense to provide APIs on it 12:54:18 ... it could be a new thing, to expose these informations 12:54:51 ... even you ask the users to annotate it, they wont 12:55:38 Topic: Performance Timeline case sensitivity issue 12:56:59 https://github.com/w3c/performance-timeline/issues/57 -> background 12:57:52 plh: https://www.w3.org/2016/09/pt-naming.html -> [test results] 12:59:08 ... name is worse, the implementation are consistent 12:59:34 yoav: I'd expect that's a string compare 13:00:11 annevk: if you give the input to two places, e.g., one is fetch, they wont find it 13:00:52 ... there's no way to tell if it's a URL or not 13:01:09 ... sad but reasonable 13:01:42 ... perhaps parse the URL, if fails, treat it as sth else; otherwise continues 13:02:36 bkardell_ has joined #WebPerf 13:03:31 s/continues/serialize it 13:05:11 ... for future, try to make it emue 13:06:14 toddreifsteck: in JS, when you create an obj, when you add attributes in it, they are case sensitive 13:07:15 igrigorik: Chrome is case insensitive for type 13:07:32 annevk: in general, you want to do case sensitive 13:07:58 mikepie_ has joined #webperf 13:08:10 ... URL are kind of case insensitive 13:09:12 action: plh to update the test, and the pull request 13:09:12 Created ACTION-172 - Update the test, and the pull request [on Philippe Le Hégaret - due 2016-09-29]. 13:10:30 yoav: Do we need to figure out the usage before we changing the behaviour? 13:11:06 igrigorik: I'll make the argument 13:11:52 shubhiepanicker: developers have no way to identify 13:12:14 toddreifsteck: How to make the existed things good enough? 13:12:20 yoav: what's missing? 13:12:46 ... when navigation started, third party provider can not detect it 13:12:57 ... when is the page loaded 13:13:31 ... finish painting... 13:13:36 mikepie__ has joined #webperf 13:14:17 nolanlawson: anything require users to write code can be done with polyfill 13:14:33 ... prefer to talk about those can't be done by polypill 13:15:55 igrigorik: for SPA, when there's a react, it relies on what's the platform 13:16:19 ... it will be nice to have easier way to detect this kind of information 13:16:58 keiji: How expensive is this? 13:17:08 rniwa has joined #webperf 13:17:26 toddreifsteck: SPA observer? 13:18:08 ... make a list, and then see what can we do 13:19:56 rniwa: end of loading for some apps is difficult to identify 13:20:25 yoav: hash change? 13:20:47 paul: developers might choose to push once 13:21:26 nolanlawson: perhaps some events to notify XHR loading is over 13:21:38 yoav: network idle? 13:22:10 paul_irish has joined #webperf 13:22:32 toddreifsteck: we need more data to talk about this topic 13:23:54 rniwa: implementation for each application differs, difficult to identify navigation starts or ends 13:23:56 olivexu has joined #webperf 13:24:15 shubhiepanicker: reasonable to go back to talk to them 13:24:27 toddreifsteck: invite them to the call on Wed 13:25:17 ... we would like to solve the problem 13:25:30 rniwa: we need to define the problem and use cases 13:26:32 ... e.g. if there's SW, do they want to info about the things inside SW 13:27:19 shubhiepanicker: we shouldn't come up with complexity metrics 13:27:40 toddreifsteck: there are some information that only the apps can tell 13:28:06 igrigorik: we have to agree on what the things are 13:29:46 rniwa: when network starts, if there are still plenty of dependencies... 13:30:03 toddreifsteck: elements on long tasks 13:30:58 paul_irish: we are already talking about supporting showing user timing and time line 13:31:25 igrigorik: it's excited to get user timing visible 13:31:45 toddreifsteck: do we want to prefix it? 13:31:57 ... spa-*? 13:32:17 yoav: make them more meaningful 13:32:52 paul_irish: some apps have lots of mark names 13:33:49 nolanlawson: dev tools should have that 13:34:19 paul_irish: yep, especially for Web Components 13:34:54 ... you visually see the name 13:36:09 igrigorik: you can subscribe to the events, and get it to the timeline 13:36:59 nolanlawson: so the hash change is there... sounds like an easy win 13:37:37 toddreifsteck: Do you want the info in the PerfObserver? 13:38:23 ... cons and pos 13:39:25 kbx has joined #webperf 13:39:26 nolanlawson: if you use push state, if you use refreshing, there nothing in the server 13:39:45 rniwa: you can still use hash and benefit from it 13:40:17 yoav: they are using hash to track changes for the server list things... 13:40:43 shubhiepanicker has joined #webperf 13:41:00 rniwa: there's no reason keep using hash 13:41:24 because pushState and popState has the same capability as overriding location.hash. 13:41:39 igrigorik: I'll open bugs on the repo and we can continue the discussion 13:44:58 igrigorik: should we introduce some structure data expect for the nicks in user timing? 13:47:12 ... provide some ways to register a mark on the timeline? 13:47:33 yoav: there is no other space on the timeline 13:48:15 rniwa: once you do that, you will have an API for the browsers to get name and so on. 13:48:21 kbx has joined #webperf 13:49:12 paul_irish: custom type is prefer 13:50:07 rniwa: perhaps more natural to sub-category 13:52:30 igrigorik: any metrics with spa- will be paint in different colour? 13:53:24 rniwa: [fig 2.] 13:56:08 plh has joined #webperf 13:56:36 igrigorik: we need convention for the timeline to identify those names 13:57:16 ... having these information will make the timeline more useful 13:58:21 rniwa: we should have the option for the perf marks to be added to the timeline 13:59:28 RRSAgent, make minutes 13:59:28 I have made the request to generate http://www.w3.org/2016/09/22-webperf-minutes.html xiaoqian 14:00:46 Topic: Battery usage, CPU usage, capacities 14:00:58 n8s: we should come up with a good defination 14:01:42 s/capacities/Device properties 14:02:03 toddreifsteck: NetInfo is current in WICG 14:02:29 https://wicg.github.io/netinfo/ -> NetInfo 14:03:03 igrigorik: NetInfo exposes connection type 14:05:01 n8s: most people is always on 3G, but the speed is hard to detect 14:05:50 igrigorik: one problem is we don't want to send user video when they are in 3G 14:05:58 n8s: yep, for the cost 14:06:24 rniwa: why does the connection type help? 14:06:50 n8s: we have a connection class lib, we open source it 14:07:11 toddreifsteck: browsers should have it 14:07:13 kbx has joined #webperf 14:07:49 yoav: it tell you something, but not everything 14:08:06 rniwa: perhaps just look at your TCP 14:08:37 igrigorik: we have product using this api 14:09:36 n8s: yep, we use connection class to detect information e.g. how long does the TCP lasts 14:10:05 facebook connection class: https://github.com/facebook/network-connection-class 14:10:45 I wrote a bit on that in the past: https://blog.yoav.ws/adapting_without_assumptions/ 14:10:48 igrigorik: what people is a magical solution, but it's impossible to provide everything 14:11:19 ... NetInfo is part of this solution 14:12:10 toddreifsteck: using both RT and NetInfo together... you might get something closed 14:13:25 yoav: we would be able to offer precise info about bandwidth, for privacy reasons 14:13:37 s/we would be able/we wouldn't be able 14:14:12 igrigorik: Battery API works in Chrome 14:15:10 n8s: connection and CPU are the big ones 14:15:52 yoav: Apps like Uber considered Battery as big thing 14:16:10 plh has joined #webperf 14:17:31 toddreifsteck: Battery is not something web developers will consider in a common case 14:18:42 igrigorik: there's an attribute about the time info of battery 14:19:44 toddreifsteck: perhaps remind the status about the battery when they request expensive actions 14:20:29 GuidoGrassel: that will be a very helpful information to write good apps 14:22:21 igrigorik: AT&T has a tool to give you an estimate about the battery status 14:24:31 n8s has joined #webperf 14:25:01 toddreifsteck: the start status, and the end status 14:25:10 igrigorik: when it comes to isolation 14:26:51 rniwa: the definition for good shape, i.e. 10%, can differ from the prospect of user and UA 14:28:21 n8s has left #webperf 14:28:32 n8s has joined #webperf 14:28:48 ... wouldn't it better for the system to notify the user? 14:29:04 ... because the browser may not be the main reason 14:29:49 yoav: low power will be interesting to expose 14:31:17 shubhiepanicker: it's good enough to provide a signal for the users 14:31:23 ... the problem is how to measure 14:32:38 igrigorik: largest consumer is screen, 2nd is network 14:39:39 olivexu has joined #webperf 14:43:16 Zakim has left #webperf 14:47:30 JFSIII has joined #webperf 14:48:07 mikepie has joined #webperf 14:53:20 yoav has joined #webperf 14:55:05 n8s has joined #webperf 14:58:57 Zakim has joined #webperf 14:59:02 RRSAgent, make minutes 14:59:02 I have made the request to generate http://www.w3.org/2016/09/22-webperf-minutes.html xiaoqian 15:00:52 kbx has joined #webperf 15:01:19 rniwa: we don't want to update these datas too frequently for the cost 15:01:57 igrigorik: if memory is low, do you get notification? 15:02:01 rniwa: yes 15:02:16 ... notify whenever the status changes 15:02:56 The proposal was to have three states: memory usage is low, high, and critical 15:03:14 toddreifsteck: modern OS acts similarly 15:03:14 And page gets a notification whenever the status changes 15:05:16 nolanlawson: Do we need normal? 15:05:42 yoav: if you are at low, you would like to know if you are out of low 15:06:47 rniwa: in iOS it's difficult to get the critical moment 15:06:52 toddreifsteck: same as windows 15:07:31 rniwa: you only get notified if you are about to be killed 15:08:27 toddreifsteck: I hope to have these in all browsers 15:09:10 rniwa: memory is the most frequency crash reason for us, good to have these 15:09:58 igrigorik: Chrome will exposed some inform, but only in window, not worker 15:10:16 toddreifsteck: this is the warning API 15:10:47 igrigorik: it's useful to have high pressure warning 15:11:11 yoav: start a thread on WICG to get more feedback 15:11:45 igrigorik: last f2f meeting we agreed on to ask feedback from the sec team to see if it's reasonable 15:11:51 rniwa: yes it's 15:13:36 n8s: you can only consider the case in the same network 15:14:20 kbx has joined #webperf 15:14:24 toddreifsteck: If I'm using 2M memory, which is high, do we want to trigger a callback? 15:14:58 rniwa: fire if it's not normal at the first time 15:16:16 yoav: if we want to add a memory hint using service worker... 15:16:32 n8s: it will be helpful to ask the best case 15:16:49 rniwa: the browser can't determine it 15:17:39 toddreifsteck: Would perfect not get to high too soon 15:19:23 rniwa: when you open the browser and watch video, if you have kill all background, by using high memory you will get low memory 15:19:43 ... we don't know why the browser is in high memory at the first place 15:19:59