| 08:35 | <kochi> | smaug: I will work on upstreaming focus stuff to HTML & DOM |
| 08:35 | <smaug> | great |
| 09:02 | <kochi> | probably mostly to HTML |
| 15:05 | <gsnedders> | annevk, Domenic: what's the status of sync XHR? do we think it's actually ever going to be killed? |
| 15:08 | <wanderview> | JakeA: how are you trying to measure memory in this test? https://cache-memory-test.glitch.me/ |
| 15:08 | <wanderview> | memory vs disk |
| 15:09 | <JakeA> | wanderview: poorly, unfortunately. I was taking processing time as an indication of what was being brought into JS. Chrome's memory devtools don't appear to be working as advertised here |
| 15:10 | <wanderview> | JakeA: I'm being told in moz irc that we probably do have said magic to put back on disk |
| 15:10 | <JakeA> | Although I was told by our engineers at blob remains disk-backed in this case, and Andew said the same happens in moz |
| 15:11 | <wanderview> | JakeA: yea, I'm wrong... https://searchfox.org/mozilla-central/source/dom/fetch/FetchConsumer.cpp#485 |
| 15:11 | <wanderview> | JakeA: I thought we only did that for IDB... we grew this "spill to file" thing at some point in the last year or so I feel like |
| 15:12 | <wanderview> | JakeA: I don't understand why its a spec violation, though |
| 15:13 | <JakeA> | wanderview: Does "read all the bytes" not suggest that? https://fetch.spec.whatwg.org/#concept-body-consume-body |
| 15:14 | <wanderview> | JakeA: it suggests it will drain the source body stream... it doesn't say where they are read too |
| 15:15 | <wanderview> | apparently we implemented the blob temp file thing for fetch in FF52 https://bugzilla.mozilla.org/show_bug.cgi?id=1312410 |
| 15:16 | <JakeA> | wanderview: https://fetch.spec.whatwg.org/#concept-read-all-bytes-from-readablestream - that would suggest that the "bytes" variable here is on disk, is that ok? |
| 15:16 | <wanderview> | JakeA: I mean, we can debate spec word smithing... but why is it a functional problem in practice? |
| 15:17 | <wanderview> | JakeA: I think our impression was that this was a non-observable thing that made the browser less crashy... win-win |
| 15:18 | <wanderview> | JakeA: and for what its worth, we *do* read it into a memory buffer, and we put it back on disk at the "package data" stage: https://fetch.spec.whatwg.org/#concept-body-package-data |
| 15:18 | <JakeA> | wanderview: I want to make sure that you can get the final byte of a 1gb resource without bringing the 1gb into memory |
| 15:19 | <JakeA> | wanderview: ohhh, so Firefox will use 1gb of memory in this case? |
| 15:19 | <wanderview> | JakeA: I think we probably stream to disk |
| 15:19 | <wanderview> | but I'm not sure |
| 15:23 | <wanderview> | JakeA: looks like we read into memory until we hit 1MB and then start streaming to disk |
| 15:23 | <wanderview> | JakeA: so some amount of in-memory buffering will happen depending on read-speed vs write-speed, etc |
| 15:23 | <wanderview> | but we should not use the full 1GB |
| 15:24 | <wanderview> | JakeA: its a bit sub-optimal that we read out of Cache API just to put back on disk... but Cache API does other things like decompressing, etc |
| 15:24 | <wanderview> | in our implementation |
| 15:25 | <JakeA> | wanderview: I think Chrome just points the blob at the same disk entry that the cache uses. I guess that means it can't really compress cache entries. |
| 15:26 | <wanderview> | JakeA: it can, its just more complicated... pretty sure we do that for IDB |
| 15:27 | <JakeA> | wanderview: yeah, I was thinking of the amount of reading required to do blob.slice() in that case |
| 15:27 | <wanderview> | JakeA: we could probably figure out how to let the blob adopt the Cache API body stream... maybe I should file a bug on that |
| 15:28 | <JakeA> | wanderview: do you reckon this is just an implementation detail then, and not worth speccing? |
| 15:28 | <JakeA> | That's where I'm leaning |
| 15:28 | <wanderview> | JakeA: sure, it would trigger a sequential read of the compressed stream which might spill back to disk... but you could avoid that until slice is called |
| 15:29 | <JakeA> | I guess you don't need to do anything until the blob is read |
| 15:29 | <wanderview> | JakeA: I think so? although the difference between file- and memory-backed blobs has been confusing for a while... it would be nice if Blob at least had a getter to say which it was |
| 15:29 | <wanderview> | but I think that is more of a Blob issue |
| 15:34 | <wanderview> | JakeA: anyway, thanks for raising this... learned more about blobs |
| 15:35 | <JakeA> | wanderview: I was thinking about polyfilling partial responses from the cache. I guess it's possible to polyfill without crashing the browser, it just may involve some disk copying |
| 15:56 | <wanderview> | JakeA: is this just because we don't have ReadableStream yet? |
| 15:57 | <JakeA> | wanderview: no, it seems like blob.slice() is a better way to handle this than streams. Eg, if I wanted to get the last 50k of a 1gb resource, it'd be inefficient to do that with streams |
| 15:58 | <wanderview> | JakeA: we should really add a skip() operation to ReadableStream |
| 15:59 | <JakeA> | wanderview: agreed. Or maybe add a seekable stream type |
| 15:59 | <JakeA> | If it's disk-backed |
| 15:59 | <JakeA> | But yeah, anything can have skip(bytes) |
| 16:00 | <wanderview> | JakeA: I think trying to make ReadableStream have a backwards-capable seek would be too breaking at this point |
| 16:00 | <wanderview> | there is some value in restricting the capabilities of the interface |
| 16:24 | <wanderview> | something you don't hear often... "Which is to say, IDB is the best and everyone should use it for everything." |
| 16:29 | <JakeA> | hahaha |
| 16:30 | <JakeA> | I've promised to write a guide to IDB for years now and I will get to it at some point. It's really not that bad once you promisify it |
| 16:51 | <wanderview> | JakeA: sadly... https://bugzilla.mozilla.org/show_bug.cgi?id=1383029 |
| 16:56 | <JakeA> | wanderview: yeah, this is down to https://bugzilla.mozilla.org/show_bug.cgi?id=1193394#c1 |
| 16:56 | <wanderview> | yea |
| 16:57 | <wanderview> | sadly we have a lot of dumb internal tests that depend on our current broken behavior |
| 16:57 | <JakeA> | You can still do the promises thing if you're only doing one thing per transaction |
| 17:11 | <annevk> | gsnedders: seems unlikely, but who knows |
| 17:12 | <gsnedders> | annevk: just, like, the text in the spec makes it sound like it will be removed |
| 17:12 | <annevk> | gsnedders: it's a bad enough feature for such a warning I think |
| 17:13 | gsnedders | now can't find the warning again |
| 17:13 | <annevk> | gsnedders: https://xhr.spec.whatwg.org/#the-open()-method second box |
| 17:13 | <gsnedders> | yeah, found it now |
| 17:13 | <gsnedders> | for some reason thought that XHR was now in Fetch |
| 17:21 | <annevk> | gsnedders: that was a plan I had, but I never did it |
| 20:33 | <jyasskin> | TabAtkins: Does `Assume Explicit For` prevent `link-for-hint` from working? I'd expected that combination to make [=foo=] look for [=hint/foo=], then [=/foo=] and then stop, but it seems to be searching for only [=/foo=]. |
| 20:34 | <TabAtkins> | I don't know, I'd have to check. |
| 20:34 | <TabAtkins> | It probably does prevent it tho. |
| 20:34 | <TabAtkins> | But you're right, it makes more sense for it to work. |
| 20:34 | <jyasskin> | Should I file a bug, or did I just get what I deserve? ;) |
| 20:34 | <jyasskin> | Cool. I'll file it. |
| 20:50 | <jyasskin> | Fetch has "user agents may, and are even encouraged to". ... isn't that "should"? |
| 21:30 | <gsnedders> | jyasskin: I'd interpret SHOULD as a stronger statement than "encouraged to" |