| 00:16 | <TabAtkins> | +1 on the addition of .closest too, annevk. Very, very useful for DOM traversal, if my authoring experience with jQuery is any indication. |
| 04:39 | <JonathanNeal> | TabAtkins: yea! closest! |
| 04:39 | <JonathanNeal> | annevk: dunno what you said to bring it up, but +1 |
| 04:41 | <JonathanNeal> | TabAtkins, annevk, “do it for the delegates” |
| 05:10 | <JonathanNeal> | my oh my it looks like it’s gonna be a thing! https://github.com/whatwg/dom/commit/fd69cc7ed9251d12b1185b24e6f89d3f0481f39d wooohoo!! |
| 05:27 | <caitp> | maybe dave methvin and john resig should be writing these things |
| 06:28 | <annevk> | JonathanNeal: I added it |
| 07:21 | <zcorpan> | annevk: SamB: so should we do something about the xhr logo? ask ajax for permission? |
| 07:25 | <annevk> | zcorpan: I don't see why it's not fair use |
| 07:25 | <zcorpan> | annevk: it is, but that's a US thing i think |
| 07:40 | <annevk> | zcorpan: not sure then |
| 07:42 | <annevk> | zcorpan: kinda planning on merging XHR into Fetch at some point so it might become moot |
| 07:43 | <zcorpan> | ok |
| 07:54 | <annevk> | darobin: tobie: you guys were involved with Ringmark right? Care to comment on https://bugzilla.mozilla.org/show_bug.cgi?id=1016053 ? |
| 07:55 | <darobin> | I wasn't, it was a Facebook internal project |
| 07:55 | <darobin> | I wasn't even aware it was still alive |
| 07:56 | <tobie> | Arg. |
| 07:56 | <darobin> | Ringmark has some... issues |
| 07:57 | <tobie> | Lots of reasons why I don't want to comment on this. |
| 07:59 | Ms2ger | wonders if he cares enough to look up who claimed they fixed all their issues, promise |
| 08:01 | <darobin> | annevk: if there are no other known instances of this being used, I would recommend closing the bug |
| 08:01 | <darobin> | also, Kyle seems to indicate that there's some XPConnect magic going on — why that would happen on the Web I don't even |
| 08:09 | <tobie> | annevk: commented. imho test needs to be fixed to generate the storageevent properly. |
| 08:13 | <Ms2ger> | tobie, want to poke the right people? :) |
| 08:13 | <tobie> | Ms2ger: Rick is. |
| 08:13 | <tobie> | Ms2ger: |
| 08:13 | <tobie> | Rick is the right person. |
| 08:13 | <Ms2ger> | Do you know if he reads bugmail? |
| 08:14 | <tobie> | He probably does, but I'll ping him on twitter. |
| 08:15 | <Ms2ger> | Ta |
| 08:31 | <tobie> | Ms2ger: are storage events still on other windows only? |
| 08:31 | <Ms2ger> | Eh? |
| 08:32 | <tobie> | Yeah. Spec used to mandate firing storage events on window objects of other open tabs of the same origin. |
| 08:33 | <tobie> | Nicely conflating a sync storage system and a cross frame communication channel along the way. |
| 08:43 | <annevk> | tobie: the test could do new StorageEvent() |
| 08:44 | <tobie> | oh. Mind mentioning that in the comment? I'm out of battery. |
| 10:18 | <annevk> | JakeA: note that per https://www.w3.org/Bugs/Public/show_bug.cgi?id=24822 we should not advocate allowing localhost by default |
| 10:19 | <annevk> | JakeA: apparently people set up systems locally and do not expect the outside world to be able to read them even if they have CORS headers... |
| 10:22 | <JakeA> | annevk: hmm, that's really tough. I mean, what if you *want* that? |
| 10:23 | <annevk> | JakeA: use case? |
| 10:24 | <annevk> | JakeA: actually, localhost same-origin is prolly fine |
| 10:25 | <JakeA> | annevk: Say I'm developing locally, and I have a local version of some API running for testing purposes |
| 10:25 | <JakeA> | annevk: Would jakearchibald.dev be able to reach localhost:3000? |
| 10:26 | <JakeA> | (assume jakearchibald.dev maps to localhost) |
| 10:27 | <JakeA> | Would XHRing to localhost:3000 behave differently to jakearchibald.dev:3000? |
| 10:27 | <annevk> | JakeA: that's what people are proposing |
| 10:28 | <annevk> | JakeA: maybe leave a comment in that bug |
| 10:28 | <annevk> | JakeA: sicking wants to do this |
| 10:30 | <JakeA> | Done |
| 10:31 | <JakeA> | tbh, as long as it was flagged in devtools with a button to allow, it'd be ok |
| 10:31 | <JakeA> | But it seems weird to break CORS like this |
| 10:36 | <darobin> | JakeA: I think it's not just CORS that's the issue but accessing localhost in general |
| 10:36 | <annevk> | Oh yeah, this wouldn't just block CORS, this would block all the things |
| 10:36 | <darobin> | there are a few apps out there that expose a local server, and aren't necessarily well thought out |
| 10:36 | <darobin> | (e.g. support GET with side-effects) |
| 10:37 | <JakeA> | But with CORS, that's an explicit "allow access" |
| 10:38 | <JakeA> | I can understand wanting to block new Image().src='http://localhost/...'; |
| 10:38 | <darobin> | JakeA: to answer your question, I would expect the block to apply to "localhost" and also explicit access to the loopback/local IPs, but not to other (unguessable) names that map to those IPs |
| 10:39 | <annevk> | Is loopback/local IPs defined? |
| 10:40 | <JakeA> | So if I had localtoast mapping to localhost it'd behave like the rest of the web? I guess that's an easy way around it for developers |
| 10:40 | <annevk> | Does the definition make sense with IPv6? |
| 10:40 | <JakeA> | (as long as localtoast doesn't become a pseudostandard) |
| 10:40 | <annevk> | If you know about any of that darobin it might make sense to add to the bug |
| 10:41 | <darobin> | JakeA: that's what I'd expect |
| 10:41 | <annevk> | JakeA: Mac OS X makes setting up localhost very easy but doesn't make the implications that clear |
| 10:41 | <darobin> | annevk: well, I don't know *much* but yes IPv6 has ::1 |
| 10:41 | <annevk> | JakeA: I guess if there was a special dev mode, localdevhost, that could work |
| 10:41 | <darobin> | it's pretty easy for developers to run their own local names |
| 10:41 | <JakeA> | annevk: Does OS X localhost come with CORS as default? |
| 10:42 | <annevk> | JakeA: this is not about CORS |
| 10:42 | <annevk> | JakeA: this is about Fetch |
| 10:42 | <JakeA> | Ahh I see, by blocking the get you also block CORS. What about forcing preflight? |
| 10:45 | <darobin> | mmmm |
| 10:45 | <darobin> | I don't like the idea of forcing preflight |
| 10:45 | <darobin> | because it means that if you develop using CORS against localhost, you get a preflight which you won't get when you deploy |
| 10:45 | <darobin> | that risks causing confusion |
| 10:46 | <darobin> | if your preflight has side-effects you'll end up with really hard to debug behaviour |
| 10:46 | <JakeA> | more than XHR failing to localhost all together? |
| 10:46 | <darobin> | well yeah, if it fails it really just fails |
| 10:46 | <darobin> | you don't get weird side effects, just immediate failure |
| 10:46 | <JakeA> | But that's also confusing |
| 10:46 | <darobin> | and your console can report "ERROR: access to localhost blocked for XHR" |
| 10:47 | <darobin> | I guess maybe there could be a better way |
| 10:47 | <JakeA> | Fair enough, if there was an option in devtools to "allow", I guess its fine |
| 10:48 | <darobin> | *if* the origin calling fetch is from a name that maps to the loopback IP, then it's allowed to call to localhost |
| 10:48 | <darobin> | anything else is just blocked |
| 10:48 | <darobin> | so jakea.dev can call localhost, with all the usual CORS stuff |
| 10:48 | <darobin> | but jakea.com, which does not map to 127.0.0.1 or ::1, can't |
| 10:49 | <darobin> | I think that stops the attacks, but keeps devs happy and simple |
| 10:49 | <darobin> | annevk: WDYT? ^ |
| 10:49 | <JakeA> | feels ok to me |
| 10:49 | <annevk> | darobin: yeah I guess something like that makes sense |
| 10:52 | <annevk> | JakeA: do you think you can get to that Fetch / SW integration question today? |
| 10:53 | <annevk> | JakeA: I'm gonna look into fetch() / Request / Response after lunch |
| 10:56 | <JakeA> | annevk: The progress events one? https://github.com/slightlyoff/ServiceWorker/issues/289 |
| 11:01 | <annevk> | JakeA: https://github.com/slightlyoff/ServiceWorker/issues/242 |
| 11:45 | <JakeA> | annevk: If I call event.respondWith(event.default()) for a subresource & it returns a redirect, it doesn't re-enter the SW right? |
| 11:46 | <annevk> | JakeA: the network layer cannot return a redirect normally |
| 11:46 | <annevk> | JakeA: only if explicitly instructed, and only the navigate algorithm does that at the moment per Hixie |
| 11:48 | <JakeA> | annevk: So when you "Return the result of performing a fetch using request", it'll have some avoid-sw flag set? |
| 11:48 | <JakeA> | (when handling 30x) |
| 11:49 | <annevk> | JakeA: yeah something like that |
| 11:49 | <annevk> | JakeA: ideally with source still pointing to the originating client, not the service worker |
| 11:49 | <annevk> | JakeA: so Referer and such are still nice |
| 11:56 | <JakeA> | annevk: If we had request.manualRedirect, which was get/set & respected by fetch(), doesn't that meet the use-cases of event.default()? |
| 11:58 | <JakeA> | .manualRedirect being true by default if its a navigate, but I could set it for subresources if I wanted. That means I'd return a redirect to fetch, which would follow it & any others (and wouldn't go through the SW because of this avoid-sw flag) |
| 11:59 | <JakeA> | If a fetch() resolves to a redirect, it'd have to be opaque because of potential tokens passed in the url |
| 12:23 | <annevk> | JakeA: what about Referer or CSP? |
| 12:24 | <annevk> | JakeA: what about the weird thing with fetch() suddenly having two modes |
| 12:24 | <annevk> | JakeA: manualRedirect is a feature, it's not a solution |
| 12:25 | <annevk> | JakeA: you can make fetch() do the same thing as default(), but what you've done at that point is that you've added a special mode to fetch() |
| 12:25 | <annevk> | JakeA: I said as much the other day |
| 12:27 | <JakeA> | annevk: If you make requests from SW, losing the Referer and CSP defaults doesn't seem bad |
| 12:28 | <JakeA> | annevk: Yeah, fetch gets a mode, is that weirder than event.default()? |
| 12:29 | <JakeA> | Having event.default() drop back into fetch and then back into SW again feels really weird, but I agree it's the only sane way to implement event.default() |
| 12:30 | <annevk> | JakeA: I would be fine actually with event.default() not going back into SW but rather do the same as "return null" |
| 12:30 | <annevk> | JakeA: but then you would not be able to store it in the cache |
| 12:30 | <JakeA> | annevk: Or more importantly IMO provide a fallback if it fails |
| 12:32 | <JakeA> | annevk: I guess event.default() would return the same promise if called twice, or just fail |
| 12:32 | <annevk> | JakeA: seems like that is up to you to define |
| 12:33 | <annevk> | JakeA: fetch() having a mode in SW context only seems weird to me |
| 12:33 | <JakeA> | annevk: event.default() means you're going to be handling SW responses in two places, for each of the calls into SW |
| 12:34 | <JakeA> | annevk: Eg, event.respondWith( event.default().then(function() { return fetch('/'); }) ) |
| 12:34 | <annevk> | JakeA: as you can see from my explanation default() is pretty weird you ask SW for a response, but it actually gives you a callback and asks you to get a response, and then that callback gives you the actual response |
| 12:35 | <annevk> | JakeA: whereas fetch() is very simple just like XHR, it just does a fetch |
| 12:38 | <JakeA> | annevk: yeah, I've got no problem with fetch(). But event.default… ugh |
| 12:38 | <annevk> | JakeA: so your solution is to make fetch() ugly? |
| 12:39 | <annevk> | JakeA: overloading is generally a bad strategy |
| 12:41 | <JakeA> | annevk: Is it overloading? The fetch spec can manually handle redirects, why shouldn't fetch() be able to do the same (but opaque for security)? |
| 12:41 | <JakeA> | Fetch already does a lot of different stuff depending on the method, headers, origin |
| 12:43 | <annevk> | JakeA: again, this is not about redirects |
| 12:44 | <annevk> | JakeA: I don't even see how that works, you get back an OpaqueResponse, it's a redirect, what happens next? You bypass the SW for future requests? What if those fail? |
| 12:45 | <JakeA> | annevk: pretty sure event.default() came about to deal with base urls after redirects |
| 12:45 | <annevk> | JakeA: it came about because there was no way to do the same thing as return null |
| 12:45 | <annevk> | JakeA: redirects expose that pretty badly, but they're not the only thing |
| 12:47 | <JakeA> | annevk: you're right, for subresources if you get a successful redirect which results in a failure, you won't hear about it in the SW |
| 12:47 | <JakeA> | hmm |
| 12:49 | <JakeA> | annevk: If event.default is the answer, your suggestion of how to hook it into the fetch spec seems the most sensible way |
| 12:50 | <yoav> | SimonSapin/TabAtkins: Around? |
| 12:51 | <SimonSapin> | yoav: yes, but just ask :) http://www.nohello.com/ |
| 12:51 | <annevk> | JakeA: again, we could overload fetch() to do this too, it would need exactly the same hooks |
| 12:51 | <annevk> | JakeA: the reasons are redirects, correct referrer, correct CSP, correct context, etc. |
| 12:51 | <yoav> | SimonSapin: I believe life has found a bug in the CSS syntax spec: https://code.google.com/p/chromium/issues/detail?id=377510 |
| 12:52 | <annevk> | JakeA: i.e. a fetch() which is passed a Request object that has its UA-bit set |
| 12:52 | <annevk> | JakeA: that solution however seems much less elegant, I'd much rather truncate the UA-bit when such an object is passed to fetch() and have fetch() always do the same thing |
| 12:53 | <yoav> | SimonSapin: Basically, when we encounter something like "+-5", we check if "-5" is a number (which it is), and then continue to parse "+-5" as a number, which fails |
| 12:54 | <JakeA> | annevk: yeah, this is why I was interested in request.send() |
| 12:54 | <SimonSapin> | yoav: that sounds wrong, let me check |
| 12:54 | <JakeA> | annevk: although that gets complicated when it comes to those requests going in & out of caches |
| 12:55 | <yoav> | SimonSapin: it's fairly possible that I got the spec wrong. This is what happens in my impl (which I think is per spec) |
| 12:55 | <yoav> | s/got/read/ |
| 12:56 | <annevk> | JakeA: the problems would seem to apply to default() too |
| 12:56 | <annevk> | JakeA: request.send() we could still do I suppose and do away with fetch() |
| 12:57 | <JakeA> | annevk: event.default().then(r => console.log(r.url)) - is exposing that a security leak given redirects? |
| 12:58 | <SimonSapin> | So. Consume a token starts with " Consume the next input code point", which becomes the "current input code point". When that’s '+', we check "If the input stream starts with a number" which works on three code points, "the current input code point and the next two input code points, in that order", so "+-5" |
| 12:59 | <SimonSapin> | … which returns false |
| 13:00 | <annevk> | JakeA: no, note that if it's opaque that would just return the empty string |
| 13:00 | <SimonSapin> | yoav: I believe the spec is correct in this case |
| 13:00 | <yoav> | SimonSapin: OK, so the first code point is the already consumed one? |
| 13:01 | <yoav> | If so, the spec's probably right, and I read it wrong |
| 13:01 | <SimonSapin> | "The algorithm described here can be called explicitly with three code points, or can be called with the input stream itself. In the latter case, the three code points in question are the current input code point and the next two input code points, in that order." |
| 13:01 | <SimonSapin> | current input code point is defined as The last code point to have been consumed. |
| 13:02 | <JakeA> | annevk: but it won't always be opaque. Say it goes to another server, then comes back with a token in the url. The response is non-opaque, but url is leaking data |
| 13:02 | <yoav> | SimonSapin: OK, thanks! I'll fix my bugs then :) |
| 13:02 | <SimonSapin> | I agree this is a bit convoluted, but I don’t know how to make it better without drowning in verbosity |
| 13:06 | <annevk> | JakeA: how would that be different from an XHR doing the same thing? |
| 13:06 | <annevk> | JakeA: btw, that's only non-opaque if it's CORS |
| 13:07 | <annevk> | JakeA: see fourth clause of step 6 of http://fetch.spec.whatwg.org/#concept-fetch |
| 13:08 | <JakeA> | annevk: Maybe I need to find out more about the redirect security issue. I thought the final request url was a problem because it may contain tokens added by another server |
| 13:08 | <annevk> | JakeA: yes it can |
| 13:09 | <annevk> | JakeA: I documented the issue here: http://fetch.spec.whatwg.org/#atomic-http-redirect-handling |
| 13:09 | <annevk> | JakeA: if you can explain to me how you would obtain that secret I'd be happy to hear it |
| 13:09 | <JakeA> | annevk: ah, so the request gets tained when it goes to the other server, but remains tained when it comes back to the local server? |
| 13:10 | <annevk> | JakeA: yes, once you're tainted there's no going back |
| 13:10 | <JakeA> | annevk: ahh ok, that's the bit that was breaking my understanding |
| 13:14 | <JakeA> | annevk: Sorry about that, I thought XHR would come back non-opaque |
| 13:14 | <annevk> | XHR would have bailed at that point |
| 13:14 | <JakeA> | yeah |
| 13:14 | <annevk> | <img> would be tainted |
| 13:15 | <JakeA> | & fetch() would return OpaqueResponse |
| 13:15 | <annevk> | So a cross-origin redirect to a same-origin URL that acts as a paint server cannot communicate using that |
| 13:16 | <annevk> | Yeah, fetch() without mode set to CORS is basically <img> |
| 13:16 | <annevk> | We need to decide what we want as default for mode |
| 13:16 | <annevk> | If it's CORS or tainted cross-origin |
| 13:18 | <jgraham> | !summon Philip` |
| 13:19 | <JakeA> | annevk: Judged by the request object I guess. I like the idea of setting "context" in the Request constructor to set defaults for headers, so probably CORS too |
| 13:19 | <jgraham> | Philip`: Any idea if http://w3c-test.org/2dcontext/fill-and-stroke-styles/2d.pattern.image.broken.html has a race between the image (failing to) load and the assert? |
| 13:19 | <jgraham> | Should there ben an event? |
| 13:19 | <JakeA> | XHR's behaviour is a good default though |
| 13:21 | <yoav> | SimonSapin: I think the source of my mixup is that impl function naming doesn't match the spec. I'll align the impl terminology with the spec's one |
| 13:22 | <SimonSapin> | yoav: you mean things like "current input code point"? |
| 13:22 | <SimonSapin> | I admit I haven’t tried to keep my impls that close to the spec |
| 13:25 | <annevk> | JakeA: I forgot the idea around context, you might want to file a bug on that |
| 13:26 | <JakeA> | annevk: https://github.com/slightlyoff/ServiceWorker/issues/279 |
| 13:27 | <annevk> | jgraham: looks like it |
| 13:35 | <annevk> | JakeA: ah right, I guess at some point that should be a bug on Fetch |
| 13:35 | <annevk> | JakeA: not sure how you'd make CORS dependant on that, most contexts allow both |
| 13:36 | <JakeA> | annevk: Is that where the Request constructor will live? |
| 13:36 | <annevk> | JakeA: yeah |
| 13:36 | <JakeA> | cool, makes sense |
| 13:37 | <yoav> | SimonSapin: Yeah, that's the part that confused me (currentCP referred to the next non-consumed CP in my impl, which I'm now changing) |
| 13:45 | <annevk> | JakeA: any reason the service worker spec has no style sheet? |
| 13:46 | <annevk> | JakeA: is that because someone updated the bs backend system again? |
| 13:47 | <JakeA> | annevk: Are we talking about https://slightlyoff.github.io/ServiceWorker/spec/service_worker/? It has styles for me |
| 13:48 | <annevk> | JakeA: so maybe it's a mixed content link somewhere that chrome doesn't block? |
| 13:48 | <JakeA> | annevk: I get styles in Firefox too |
| 13:48 | <JakeA> | Even in the nightlies |
| 13:48 | <tobie> | Happens to me from time to time. Not sure what it is. |
| 13:49 | <annevk> | JakeA: I use 32.0a1 (2014-05-27) |
| 13:49 | <annevk> | Console says "Error: https://slightlyoff.github.io/ServiceWorker/spec/assets/web-spec-framework/bower_components/platform/platform.js is being assigned a //# sourceMappingURL, but already has one" |
| 13:49 | <JakeA> | I get styles in 32.0a1 (2014-05-21). Updating now |
| 13:49 | <annevk> | Sounds like dependency management gone wrong |
| 13:49 | <JakeA> | I get that error too, but still get styles |
| 13:49 | <annevk> | Oh |
| 13:50 | <annevk> | I don't understand why this spec has such a complex setup :/ |
| 13:50 | <annevk> | There's a gazillion script files |
| 13:50 | <JakeA> | annevk: Hmm, yeah, no styles in 32.0a1 (2014-05-27) |
| 14:14 | <tobie> | annevk: yeah, it's difficult to deal with. Breaks when parsed with anything but a modern browser (e.g. jsdom doesn't support it very well) |
| 14:15 | <tobie> | Hard to get the ToC out as it's inside an iframe. Etc. |
| 14:18 | <jgraham> | annevk: Welcome to the web of the future |
| 14:21 | <annevk> | JakeA: is the current class distinction between response objects useful? |
| 14:21 | <tobie> | jgraham: yeah, sincerely hope Web components are more straightforward than the current polyfills. If not, we're in for a world of hurt. |
| 14:21 | <annevk> | JakeA: how about a single object with a property to inspect what kind you have? |
| 14:21 | <annevk> | JakeA: requiring typeof seems not really JavaScript-y |
| 14:24 | <JakeA> | annevk: I don't have a strong opinion |
| 14:24 | <annevk> | JakeA: so if new Request takes (url, init), should new Response take (body, init)? |
| 14:25 | <JakeA> | annevk: yes |
| 14:25 | <JakeA> | annevk: https://github.com/slightlyoff/ServiceWorker/issues/192#issuecomment-40737493 |
| 14:26 | <annevk> | JakeA: k, sketching out API in Fetch now |
| 14:34 | <annevk> | JakeA: open issues in my API sketch are body and header representation |
| 14:37 | <zewt> | "can you elaborate" in this instance, guessing not |
| 14:43 | <annevk> | zewt: ? |
| 14:51 | <annevk> | JakeA: http://fetch.spec.whatwg.org/#fetch-api |
| 15:06 | SamB | isn't sure he likes the future |
| 15:06 | SamB | also wonders when he gets his jetpack or flying car |
| 15:23 | <JakeA> | annevk: looks good, I'll have a think how to provide default values to Request based on a context (maybe context is enough) |
| 15:23 | <annevk> | JakeA: that'd mean we'd have a distinct context and context-for-CSP, which may be okay, but it's yet another field |
| 15:24 | <annevk> | JakeA: should prolly discuss that with implementers |
| 15:24 | <JakeA> | annevk: the alternative is different request constructors. ImageRequest, FontRequest etc etc |
| 15:24 | <JakeA> | bleh |
| 15:25 | <annevk> | JakeA: no, the alternative is not having the feature |
| 15:25 | <annevk> | JakeA: syntax for the feature is a separate discussion ;-) |
| 15:25 | <annevk> | (though just a field seems fine, if we do it) |
| 15:37 | <dglazkov> | good morning, Whatwg! |
| 17:22 | <Philip`> | jgraham: The test should not run until window.onload, and I probably assumed onload would not be triggered until the image had either succeeded or failed to load |
| 17:23 | <Philip`> | Maybe in theory it's possible for the browser to realise the image cannot succeed, so it decides to send the load event, but doesn't actually mark the image as failed until some arbitrary later time |
| 17:23 | <Philip`> | though that would seem silly |
| 17:23 | Philip` | has no idea what the spec said when he wrote the test, and even less idea what it says now |
| 17:24 | <jgraham> | Philip`: Yeah, I realised that. It seems like browsers are wrong in not firing an error there, although they will if the PNG header is corrupted |
| 17:25 | <jgraham> | (I mean firing an error in the canvas operation; I *think* the cases are expected to differ on whether there is a load event for the image) |
| 17:25 | <jgraham> | Additionally it seems like there is some kind of network race in Gecko |
| 17:26 | <Philip`> | I vaguely remember that the whole thing with images loading/failing was a total mess in implementations and in the spec, so I didn't look at it too closely |
| 17:27 | <jgraham> | Maybe I should just file a bug on Gecko saying "this seems to race" and disable the test |
| 17:30 | <Philip`> | That sounds like shirking responsibility for the problem |
| 17:30 | <Philip`> | so I approve |
| 17:43 | <jgraham> | Sadly, my taking responsibility for every problematic test is a non-converging approach since we are adding new non-deterministic tests faster than I resolve the issues with existing ones. |
| 17:44 | <jgraham> | So it's a necessary solution :( |
| 17:45 | <SamB> | maybe there should be some kind of policy where the people who add the races need to handle it |
| 17:49 | <jgraham> | SamB: Sadly there are a bunch of reasons that doesn't work |
| 17:49 | <jgraham> | Like it isn't clear who added the race |
| 17:50 | <jgraham> | It isn't clear how important the race is |
| 17:50 | <SamB> | that second one looks harder |
| 17:50 | <jgraham> | It's difficult to reproduce the race on other hardware/configurations/whatever |
| 17:50 | <SamB> | hmm |
| 17:51 | <SamB> | and is it hard to reproduce that configuration to bisect the issue? |
| 17:51 | <jgraham> | In general intermittent tests are the bane of web browser testing |
| 17:51 | <SamB> | and I guess intermittence is hard to determine for sure itself |
| 17:51 | <SamB> | that's the crux, huh? |
| 17:53 | <jgraham> | Yeah, everything is hard when bugs are intermittent |
| 19:22 | <TabAtkins> | annevk: You around? I think there's some miscommunication about the "status" thing in Font Loading. Basically, I have no idea what you're talking about. ^_^ |
| 19:23 | <TabAtkins> | The "status" is an exposed enumerated attribute on the FontFace object. I don't understand what further needs to be done about when it gets set, since the algo that sets it is already async, unless maybe the entire async portion of the algo (and all the rest of my async algos) need to specify what task queue they run in? |
| 19:52 | <annevk> | TabAtkins: in step 4 you set status to "loading"; my question is if anyone can ever observe status being "loading" |
| 19:52 | <annevk> | TabAtkins: and how they are notified of that change that they can now observe such a thing |
| 19:52 | <TabAtkins> | Oh, now I see what you're saying! |
| 19:52 | <jarek> | will Web Components support SVG templates? |
| 19:52 | <jarek> | e.g. will it be possible to do: <link rel="import" href="/someFile.svg"> |
| 19:53 | <TabAtkins> | Yeah, whether or not that's observable is a good question. |
| 19:53 | <annevk> | TabAtkins: if in an async algorithm you don't define when a state transition in the main thread happens, you risk obj.status != obj.status due to the asynchronous nature of things and that would be bad |
| 19:54 | <TabAtkins> | You can certainly observe "loading" at a well-defined time if you have a url-based font - it switches sync when you or the system calls .load(). |
| 19:54 | <TabAtkins> | But in the binary data case, hm. |
| 19:54 | <TabAtkins> | Okay, so pretend that I want to make it observable. How do I fix this? Push the rest of the algo past that point into another task? |
| 19:54 | <TabAtkins> | Or queue a task to set it to "loading"? |
| 19:55 | <TabAtkins> | (and then queue another one to set it to "loaded" or "error"?) |
| 19:56 | <annevk> | TabAtkins: I don't get why for the parsing case you need to set it to "loading" |
| 19:57 | <annevk> | TabAtkins: it seems like you should just set it to "loaded" or "error" and that's sufficient |
| 19:57 | <TabAtkins> | It might not be necessary, sure. |
| 19:57 | <TabAtkins> | But it looks like your objection extends to the loaded/error case, too, right? |
| 19:57 | <annevk> | TabAtkins: no, those are observable due to the promise being resolved/rejected |
| 19:57 | <annevk> | TabAtkins: the "loaded" case has no corresponding task |
| 19:58 | <annevk> | TabAtkins: well actually, you're right I guess |
| 19:58 | <annevk> | Domenic: you might want to mention this in your guide |
| 19:58 | <annevk> | Domenic: if you set observable state in addition to rejecting/resolving a promise, that ideally happens in the same microtask |
| 19:59 | <TabAtkins> | Is it implicit that promise resolving always happens in some microtask? |
| 19:59 | <TabAtkins> | Rather than async sometime in the middle of your executing code? |
| 20:00 | <TabAtkins> | (Or maybe it doesn't matter, because *responding* to a promise always happens in the next microtask.) |
| 20:00 | <annevk> | TabAtkins: promise resolving can happen whenever, since it's only observable in a microtask |
| 20:00 | <annevk> | TabAtkins: however, if you resolve and change observable state at the same time, there's a potential problem that Domenic needs to solve |
| 21:15 | <Domenic> | annevk: I felt this was kind of covered in the guide |
| 21:16 | <Domenic> | Queued tasks take place after next microtask |
| 23:33 | <JonathanNeal> | What’s the status of Element.prototype.findAll / find? Is that still happening? |
| 23:35 | <Hixie> | anyone here a JS module expert who can answer me some questions? I'm trying to work out if I can walk the dependency tree using the ES6 module API |
| 23:35 | <zewt> | still dubious about adding an api entry point that's basically just an alias for something else |
| 23:38 | Hixie | starts a sentence "HTML Imports import other Imports" and then realises he's gonna have to start over |
| 23:45 | <astearns> | HTML imports importing other imports is an important feature |