| 08:02 | <hsivonen> | GPHemsley: thanks. I posted http://lists.w3.org/Archives/Public/public-css-testsuite/2015Jan/0016.html |
| 09:58 | <annevk> | http://intertwingly.net/blog/2015/01/11/URL-Work-Status is somewhat hard to grok. The barrier to entry at the WHATWG is too high, yet everywhere else he hits a door. |
| 10:13 | <hemanth> | 'http://f: 21 / b ? d # e' interesting |
| 10:16 | hemanth | tried to reflect on ES6 Reflect API http://h3manth.com/new/blog/2015/es6-reflect-api/ |
| 10:58 | <MikeSmith> | annevk: https://twitter.com/ttepasse/status/554341595185946625 |
| 10:58 | <annevk> | "fora⊙an" that's a long time ago |
| 10:59 | <MikeSmith> | 2005 it seems |
| 11:01 | <annevk> | That was at Opera, around the time of Opera's 10 year anniversary and around the time of me getting hired for a longer period |
| 11:04 | <MikeSmith> | then before I started at Opera |
| 11:05 | <annevk> | I guess I switched to using @opera.com a little later, when everything was more permanent |
| 13:34 | <MikeSmith> | https://community.rapid7.com/community/metasploit/blog/2015/01/11/google-no-longer-provides-patches-for-webview-jelly-bean-and-prior |
| 13:35 | <MikeSmith> | seems pretty surprising if true |
| 13:38 | <caitp> | it's pretty sad for people who are contract-tied to their old phones and can't upgrade yet, or who are financially unable to upgrade |
| 13:38 | <caitp> | but surprising? |
| 13:50 | <annevk> | Hmm, I wanted to write about custom elements, but I think I should first explain web platform objects... Turtles, meh |
| 17:17 | <wanderview> | JakeA: annevk: if content runs window.caches.addAll(requests)... should those be intercepted by ServiceWorker? Does Cache add()/addAll() implicitly get the skip service worker flag? |
| 17:18 | <annevk> | wanderview: I feel like they should go through the worker |
| 17:18 | <wanderview> | annevk: unless initiated by the ServiceWorker? |
| 17:18 | <annevk> | wanderview: fetches from a service worker can never go through that service worker |
| 17:19 | <annevk> | (nor any other one at the moment, but it seems like that might change going forward) |
| 17:20 | <annevk> | wanderview: that should happen automatically in Fetch due to the associated client of the request |
| 17:21 | <wanderview> | annevk: yea... its a quirk of our cache add/addAll implementation that we don't get it automatically... Cache is using a lower level API |
| 17:23 | <JakeA> | wanderview: agree with annevk |
| 17:23 | <wanderview> | thanks |
| 17:24 | <wanderview> | so we can have window cache.addAll()... go to SW which then does more Cache operations |
| 17:24 | <wanderview> | nested within the cache.addAll() |
| 17:27 | <annevk> | turtles! |
| 17:28 | <annevk> | but yeah, that might get hairy quickly |
| 17:28 | <annevk> | need some kind of atomicity otherwise you get races |
| 17:30 | <wanderview> | I think this probably is mostly ok since the spec is written async with many operations in flight already |
| 17:30 | <wanderview> | its kind of tricky for the gecko implementation, though... |
| 17:35 | <JakeA> | annevk: if a call results in an error that isn't speced (perhaps implementation specific), should the browser throw the most appropriate error, or its this a signal that the implementation or the spec is wrong? |
| 17:37 | <JakeA> | annevk: I guess what I'm asking is: are there specs that loosely define throwing like "if an error occurs, throw an appropriate error" |
| 17:37 | <JakeA> | (feels like insufficient specing to me) |
| 17:38 | <Ms2ger> | There's lots of insufficient speccing |
| 17:38 | <Ms2ger> | Like HTML "if a network error occurred" |
| 17:40 | <jgraham> | The bit after the comma seems particularly poor though |
| 17:40 | <jgraham> | The nature of the error shouldn't be left to chance^Wdevelopers |
| 17:47 | <annevk> | JakeA: that would be a bug in the spec |
| 17:48 | <annevk> | JakeA: the only thing we're loose on is the error message, as that can be localized and such |
| 17:55 | <JakeA> | annevk: thought so, ta |
| 18:33 | <jgraham> | Does anyone know what happened to the testharness.js-based Chromium Wervice-Worker tests? |
| 18:33 | <jgraham> | Did they ever get submitted to wpt? |
| 18:34 | <jgraham> | Probably the ones at https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/LayoutTests/http/tests/serviceworker/&q=service-worker&sq=package:chromium&type=cs |
| 18:35 | <Ms2ger> | Speaking of chromium tests |
| 18:35 | <Ms2ger> | jsbell, any news on TextEncoder/Decoder? |
| 18:38 | <jgraham> | Seems like jsbell might also be able to help with my question |
| 18:38 | Ms2ger | approaches jsbell from behind |
| 18:39 | <jsbell> | Ms2ger: thanks for the ping... I started to move some of them my local w-p-t repo before the holidays, need to get back to it. |
| 18:39 | <jsbell> | ... into my local... |
| 18:39 | <Ms2ger> | Nice to hear that |
| 18:39 | <jsbell> | jgraham: ?? |
| 18:39 | <Ms2ger> | <jgraham> Does anyone know what happened to the testharness.js-based Chromium Wervice-Worker tests? |
| 18:39 | <Ms2ger> | <jgraham> Did they ever get submitted to wpt? |
| 18:39 | <Ms2ger> | <jgraham> Probably the ones at https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/LayoutTests/http/tests/serviceworker/&q=service-worker&sq=package:chromium&type=cs |
| 18:40 | <Ms2ger> | jsbell, fwiw, smaller PRs tend to get landed quicker, so you don't necessarily need to wait until you've got them all |
| 18:40 | <jsbell> | not submitted yet, we still plan to |
| 18:41 | <jgraham> | jsbell: If you can get them submitted we can get them reviewed (although technically that's not needed if you are confident they're good to go) |
| 18:41 | <jgraham> | jsbell: The Mozilla implementors would like to run them |
| 18:42 | <jsbell> | jgraham: I'll chat w/ the team tonight, see if anyone can take it on. (new quarter, new priorities, yadda yadda) |
| 18:42 | <jgraham> | Yup |
| 18:42 | <jgraham> | If you need any help let me know |
| 18:42 | <jgraham> | Like, if it's as simple as "copy the files from the Chromium tree into the wpt tree" I can just do that for you ;) |
| 18:52 | <jsbell> | jgraham: you're welcome to give it a shot. The big issue is likely to be that we don't run them w/ serve.py so many likely have assumptions about our test server config that'll need correcting |
| 18:53 | <Ms2ger> | jsbell, any news on moving to wptrunner? |
| 18:54 | <jsbell> | ms2ger: no news |
| 18:55 | <jgraham> | jsbell: OK, great. Like I say we have interest in running these which I assume (optimistically!) means we have resources to make it happen ;) |
| 18:57 | <wanderview> | yea... the tests were helpful when I ran them manually... it would be nice to get them imported before we ship |
| 18:57 | <Ms2ger> | wanderview, put it on your todo list :) |
| 18:58 | <wanderview> | Ms2ger: the last time I checked the blink folks were waiting on PRs in review with jgraham... once they uplift them to the wpt repo I don't think there is much for us to do besides pull them in |
| 18:59 | <wanderview> | it seems we're past that point now, though... so hopefully they can get uplifted |
| 19:00 | <jgraham> | Right, the testharness.js changes landed |
| 19:04 | <wanderview> | cool |
| 20:03 | <TabAtkins> | annevk: The mutation events crashers were about people using nodes exposed by mutation events (particularly removal events) and making more mutations in/with them - they were incompletely sterilized and still thought they had some sort of connection to the DOM, which causes inconsistent state when mutating, and eventually hits crashes. |
| 20:03 | <TabAtkins> | It's like the problems with the instance tree in <use> - nothing inherent to the tech, but persistent crashiness due to human frailty in coding, and that just being something which regularly exposed such problems. |
| 20:08 | <annevk> | TabAtkins: there are some concerns around synchronous mutation that would be relevant here |
| 20:08 | <TabAtkins> | annevk: Likely, yeah. People could be hanging onto references to the old version of the element. |
| 20:09 | <annevk> | well there's no old version in solution 1) |
| 20:09 | <TabAtkins> | Yeah, but there's all the ordering and raciness there. :( |
| 20:10 | <annevk> | why? |
| 20:10 | <TabAtkins> | I explained in the email, I thought. Is it still unclear? |
| 20:11 | <annevk> | yeah I guess, not sure it's insurmountable |
| 20:12 | <TabAtkins> | It's not insurmountable, it's just a persistent annoyance. Upgrading makes things more declarative, which matches the spirit of using HTML better. |
| 20:12 | <TabAtkins> | If you could only use custom elements by constructing them, it wouldn't matter - the ordering constraints of JS would make the right behavior fall out. |
| 20:14 | <annevk> | if you ensure your dependencies are loaded you can have constructors during parsing |
| 20:14 | <TabAtkins> | "if you ensure" is the hard part. It means, for example, that you need to load your element definitions in a sync script block before your markup. |
| 20:55 | <Hixie> | annevk: lol. if the barrier to entry is too high when the barrier is one's own ability to do the work... |
| 20:56 | <Ms2ger> | mailing list is a support forum |
| 21:30 | jgraham | wonders how long checking out blink is supposed to take |
| 21:30 | <miketaylr> | multiple hours, last i did that |
| 21:34 | <roc> | TabAtkins: FWIW the problems Blink had with <use> may have been Blink's approach, not inherent. We always had a simple cloning strategy and didn't seem to have these problems |
| 21:35 | <roc> | mutation events, on the other hand .... blergh |
| 21:35 | <jgraham> | miketaylr: I'm up to 1:45 and no end in sight |
| 21:36 | <jgraham> | But my internal monolouge of the process has started to sound like the narration of a castaway |
| 21:36 | <miketaylr> | heh |
| 21:37 | <miketaylr> | be sure to find a volley ball to keep you company |
| 22:31 | <jgraham> | Hmm, so 2.5 hours in chromium checkout failed due to low disk space |
| 22:33 | <Ms2ger> | It's what, 50GB? |
| 22:38 | <jgraham> | I hope not |
| 22:39 | <jgraham> | If it is then even deleting B2G isn't going to help |
| 22:40 | <Ms2ger> | "Either way, fetch checks out more than 10GB" |
| 22:40 | <Ms2ger> | Sounds like I overestimated a bit |
| 22:40 | <jgraham> | I think I had 16 when it stopped |
| 22:41 | <jgraham> | B2G is 26, but I think that's almost all android |
| 23:44 | <jamesr__> | my chromium checkout is roughly 20GB, excluding build artifacts |
| 23:45 | <jamesr__> | debug build is 27GBish, depending on configuration |
| 23:45 | <jamesr__> | and what targets you wanna build |
| 23:48 | <caitp-> | that's my favourite thing about v8 |
| 23:48 | <caitp-> | tiny |