| 06:42 | <zcorpan> | krijnhoetmer: http://www.downforeveryoneorjustme.com/http://krijnhoetmer.nl/irc-logs/whatwg |
| 08:25 | <jgraham> | hsivonen: I have mentioned to the Servo people several times that document.write is non-trivial to implement |
| 08:25 | <jgraham> | Hopefully kmc will work on it in Q2 or something, but I'm not sure |
| 08:40 | <annevk> | JakeA: my main concern now with your cancelable promises proposal is that Domenic doesn't like it |
| 08:40 | <annevk> | JakeA: that doesn't bode well for standardizing it |
| 08:48 | <JakeA> | annevk: yeah, if Domenic doesn't like it, it's probably wrong :D - will chat with him later and find out why |
| 08:50 | <annevk> | GitHub seems super slow or something is wrong with my network... |
| 08:50 | <JakeA> | Could always add .abort() to the return promise but not any additional promises. The token solution is soooooo ugly, I'm surprised it has so much backing |
| 08:50 | <annevk> | Nah, just GitHub |
| 08:51 | <JakeA> | annevk: they're being ddos'd |
| 08:51 | <JakeA> | https://twitter.com/githubstatus/status/581372857353154560?s=09 |
| 08:52 | <annevk> | Okay, I guess I'll wait a bit then |
| 08:52 | <annevk> | JakeA: yeah, that's the terminate() idea, while reserving the names abort() / cancel() for future efforts |
| 08:53 | <annevk> | not super elegant, but does seem better than the token thing, agreed |
| 08:58 | <MikeSmith> | I heard it through the grapevine that "Upgrade Insecure Requests" support may be landing soon |
| 08:58 | <MikeSmith> | if so that's a pretty amazing success story of going from "gleam in someone's eye" to shipping feature in record short time |
| 09:03 | <annevk> | Ooh, I think I'll introduce "redirect mode" |
| 09:03 | <annevk> | With "follow", "error", and "manual", and expose only the first two to script |
| 10:12 | <JakeA> | annevk: re media key event targeting, I think it's the element that should request the global lock for media key events |
| 10:14 | <annevk> | JakeA: makes sense |
| 11:39 | <JakeA> | annevk: If background sync is split into .sync and .periodicSync, we should probably have separate ServiceWorker events |
| 11:56 | <annevk> | JakeA: yeah I think that would make sense |
| 11:57 | <annevk> | JakeA: they are quite distinct and can have completely different UI flows too |
| 11:57 | <JakeA> | annevk: agreed, different use-cases too |
| 12:41 | <annevk> | x => y is such a convenient way to write a function |
| 12:53 | <jgraham> | Yeah, I hope that quells some of the complaints about testharness.js being too verbose |
| 13:17 | smaug____ | being old and cranky code reviewer thinks => is good for writing code, but bad for reading it |
| 13:18 | <smaug____> | luckily I review .js very rarely |
| 13:18 | <smaug____> | (except tests) |
| 13:41 | <JakeA> | I only use "function" when it's the only way to create a named function, or for when I want the "this" value to change, which is rarely |
| 14:42 | <JakeA> | Domenic: I realise you've gone through this a ton of times, but could you explain why cancellable promises are bad? A link will do |
| 15:50 | <wanderview> | JakeA: response.body.cancel() is shipped? |
| 15:50 | <JakeA> | wanderview: hmm, yeah, misleading wording. I mean it's in Canary |
| 15:50 | <JakeA> | wanderview: Thanks for pointing that out |
| 15:50 | <JakeA> | Updated the post |
| 15:51 | <wanderview> | I guess it was more I didn't realize .cancel() was on ReadableStream |
| 15:52 | <wanderview> | but I'm happy to be the pedantic police too :-) |
| 15:52 | <JakeA> | wanderview: yep! https://streams.spec.whatwg.org/#rs-class |
| 15:53 | <wanderview> | JakeA: so, what happens if someone does cache.put(req, resp).then(function () { resp.body.cancel(); })? |
| 15:53 | <wanderview> | and the cancel fires before the body is written to the cache |
| 15:54 | <JakeA> | "If IsReadableStreamLocked(this) is true, return a promise rejected with a TypeError exception." |
| 15:54 | <JakeA> | I imagine the cache has a lock |
| 15:55 | <wanderview> | yea... I guess they would just have to do cache.delete(req) and then eat the wasted bandwidth usage? |
| 15:56 | <wanderview> | JakeA: seems like it could do whatever Cache is supposed to do if the network errors out while getting the body, but after headers have been committed to cache |
| 15:56 | <JakeA> | wanderview: Unless .put returns *jazz hands* a cancellable promise |
| 15:56 | <wanderview> | (which I don't currently understand) |
| 15:56 | <wanderview> | JakeA: I don't think cancellable promise helps here... since we changed Cache.put() to resolve that promise before the body is written to disk |
| 15:56 | <wanderview> | right? |
| 15:56 | <JakeA> | Good point |
| 15:57 | <wanderview> | JakeA: I suppose we could make Cache.put() promise resolve with another promise representing body completion |
| 15:57 | <annevk> | Very nice that document.URL and document.documentURI are made compatible in Chrome |
| 15:58 | <JakeA> | wanderview: a promise can't resolve with a promise, but it could be an object with a promise hanging off it I guess |
| 15:58 | <wanderview> | no? hmm |
| 15:59 | <wanderview> | that seems a weird restriction |
| 16:00 | <wanderview> | JakeA: has chrome implemented committing to Cache when headers are available? |
| 16:01 | <JakeA> | wanderview: if you resolve a promise with a promise, it unwraps the promise and resolves with the underlying value. Eg Promise.resolve(fetch(url)) resolves with a response, not a fetchPromise |
| 16:02 | <wanderview> | I see... I guess that makes sense |
| 16:02 | <JakeA> | wanderview: ummmm, I'm not completely sure to be honest. We *should* have |
| 16:02 | <wanderview> | JakeA: I'm still hazy on what Cache is supposed to do on network error when writing the body |
| 16:02 | <wanderview> | I should try to decipher that part of the spec I suppose |
| 16:03 | <wanderview> | although I think it might not be spec'd... since it just says "may commit when headers available" and async body writing is not even really mentioned anywhrere else |
| 16:03 | <wanderview> | so I was curious what chrome did today |
| 16:04 | <wanderview> | hmm... seems the spec only does early resolve for add()... not put() |
| 16:04 | <wanderview> | oh... nm |
| 16:07 | <wanderview> | JakeA: wrote an issue: https://github.com/slightlyoff/ServiceWorker/issues/665 |
| 16:12 | <JakeA> | wanderview: Cheers! |
| 16:15 | <wanderview> | I have to admit... from a purely abstract point of view it seems to make more sense to make the thing producing the Promise to have cancel then on the Promise itself |
| 16:15 | <wanderview> | but my eyes also glaze over when trying to read that github issue |
| 16:31 | <JakeA> | wanderview: I don't think Domenic likes it, which probably means there's a big flaw with it that I haven't seen yet |
| 16:33 | <wanderview> | JakeA: it just seems that a "promise of future behavior" conceptually does not grant control over anything... its just a notification mechanism |
| 16:35 | <JakeA> | wanderview: yeah, I get that a cancellable promise breaks that, but I'm not sure why it's a problem in this case. |
| 16:39 | <wanderview> | JakeA: yea... I meant from a theoretical abstract point of view... I guess you are proposing that Promises "forget" the operation and a cancel occurs if they all forget? |
| 16:39 | <wanderview> | from the talk about ref counts |
| 16:41 | <JakeA> | wanderview: yeah, if all cancellable children enter a cancelled state, as should the parent |
| 16:41 | <wanderview> | but you can have some children that are not cancellable? |
| 16:42 | <JakeA> | wanderview: Promise.resolve(cancellablePromise) creates a non-cancellable child |
| 16:43 | <wanderview> | JakeA: seems like many people may not understand this distinction... |
| 16:44 | <wanderview> | JakeA: don't get me wrong... I want cancellable fetch too... but this seems like footgun territory |
| 16:55 | <annevk> | Do we really want cancelable fetch? I'm personally curious if we can set a record in developer table flipping. |
| 16:58 | <wanderview> | annevk: you know... April 1 is coming up... you could have some fun here |
| 16:59 | <jgraham> | Tell people that we heard they wanted cancellble fetch, so we cancelled fetch and they will have to use XHR instead. |
| 16:59 | <wanderview> | fetch has been renamed XHR2 |
| 16:59 | <annevk> | slowclap |
| 16:59 | <caitp-> | it's potentially a big deal for mobile |
| 17:01 | <gsnedders> | How does fetch work wrt HTTP2 server push? |
| 17:02 | <wanderview> | annevk: image you are using fetch() to stream https://github.com/whatwg/fetch/issues/27 and want to stop reading because its never ending... how do you cancel the fetch? |
| 17:02 | <annevk> | gsnedders: can't tell if joke or honest question |
| 17:03 | <wanderview> | mine was a joke |
| 17:07 | <gsnedders> | annevk: semi-serious. what happens if the server initates another response in response to the request? is it just assumed the UA cancels it? |
| 17:08 | <annevk> | gsnedders: it would just be used for the next identical request afaik |
| 17:08 | <annevk> | gsnedders: push stuff is handled by the network layer / network cache |
| 17:09 | <gsnedders> | I thought normally some stuff crossed that boundary, but I could be misremembering |
| 17:12 | <annevk> | gsnedders: if that actually happened that would mean every context we know would be affected, no? |
| 17:12 | <annevk> | gsnedders: that would not be a great upgrade of the network layer |
| 17:12 | <annevk> | (not saying we could not do something with push if we wanted to at some point) |
| 17:14 | <gsnedders> | annevk: I thought there were interactions with the pre-parser in most impls, but idk. Obviously just cancelling it immediately or just caching it in case it's requested are plausible. |
| 18:02 | <bradleymeck> | gsnedders: the same, your main payload will come in, and push will be cached |
| 18:03 | <bradleymeck> | i assume it doesn't do sorcery... but I could be wrong |
| 18:31 | <JakeA> | wanderview: I think you're right btw, normal promises should count as refs |
| 19:39 | <wanderview> | JakeA: it does seem not being able to cancel .json()/.text()/etc reduces their utility |
| 19:39 | <wanderview> | you basically can't use them if you think you might need to cancel the stream |
| 19:40 | <wanderview> | Domenic: why do streams require the lock in order to cancel? |
| 19:58 | <Domenic> | Lots of scrollback here, not sure how much of it I can reply to on my iPad… |
| 19:59 | <Domenic> | Streams required lock in order to cancel because if you have a lock then nobody should be able to interfere with you. |
| 20:00 | <Domenic> | We envision .json() etc., as well as pipeTo, returning cancellable promises (I.e., supporting cancellation tokens) |
| 20:01 | <Domenic> | JakeA: the main thing that immediately made me flinch from your proposal is that it treats cancel on the same ground as fulfill and reject. I don't think it's at all analogous. It would need to be separated, for sure. |
| 20:02 | <wanderview> | Domenic: thanks |
| 20:03 | <wanderview> | Domenic: although I'm not sure I see cancel in the same light as other operations on the stream... even if you have a lock it seems the source could encounter an error and cancel() is just one type of error |
| 20:04 | <Domenic> | Cancellable promises are not bad, but we don't want to give out the ability to cancel to everyone who holds the promise. It's probably ok though for some types of operations to return a promise while also returning the capability to cancel itself, as long as that's not baked in to all promises ever |
| 20:05 | <Domenic> | wanderview: well cancel() makes things closed, not errored, but yes, I agree. That's a big capability leak though. The same reason we don't have p.resolve() / p.reject(), instead reserving those for the creator |
| 20:06 | <Domenic> | Not exactly the same, but the same category of hazard |
| 20:06 | <wanderview> | hmm, ok |
| 20:07 | <Domenic> | I agree it's not immediately clear and could perhaps be a judgment call. But the only reason I wanted it was to be able to cancel pipes/json/etc. and then I realized those should just be cancelable promises |
| 20:10 | <wanderview> | Domenic: I guess its confused in the github issue because the world where you would use body.cancel() does not contain cancelable promises... I mean, they are being discussed as alternatives to one another |
| 20:14 | <Domenic> | O_o |
| 20:14 | <Domenic> | How do you cancel before the headers arrive then |
| 20:14 | <wanderview> | Domenic: some fetch extension or something |
| 20:15 | <Domenic> | I unsubbed from the issue btw |
| 20:15 | <wanderview> | Domenic: but put cancelation on the source, not the promise |
| 20:15 | <Domenic> | Well I mean you could use the same mechanism for cancelling .json etc. |
| 20:16 | <Domenic> | When I say "cancelable promise" I don't necessarily mean a promise with a .cancel() method |
| 20:16 | <wanderview> | I should probably just defer to annevk or JakeA here... I have not kept up with the issue as well as they have |
| 22:11 | <JakeA> | Domenic: do you have some time on Monday to go through this with me? |
| 22:17 | <Domenic> | JakeA: yeah definitely. |
| 22:40 | <JakeA> | Domenic: ta, I'm sure it'll be retreading old ground, but fetch is getting a lot of flack for it |
| 23:01 | <Domenic> | yeah, people really don't seem to have taken the bicycle analogy to heart |
| 23:59 | <scheib> | dtseng: Look at https://build.chromium.org/p/chromium.linux/builders/Linux%20Tests/builds/22541 |