| 07:58 | <annevk> | I think I understand browsing contexts now |
| 08:32 | <tobie> | ^ ... |
| 08:33 | <tobie> | annevk: it's reassuring to hear from people so knowledgeable about the platform how complex it really is. |
| 08:33 | <tobie> | annevk: you should do this at least weekly. |
| 08:33 | <tobie> | annevk: it would boost morale. |
| 08:33 | <tobie> | ;) |
| 08:34 | <annevk> | It is really complex |
| 08:36 | <annevk> | The main way I seem to learn is to dive into something. Get stuck. Do other things for six months. Get back to it and maybe understand or get stuck again. Repeat until it's understood. |
| 08:37 | <annevk> | It's not entirely clear what happens in those six months (or longer), but somehow being away for a while makes it easier to tackle it next time around. Noticed this happening a few times now, but maybe confirmation bias. |
| 08:39 | <annevk> | tobie: a large part of the problem is also that browsers and standards are sometimes out-of-sync and that standards describe things in a rather unclear way, often with bugs |
| 08:39 | <annevk> | (or there simply is no standard) |
| 08:40 | <tobie> | annevk: I'm totally with you on the background processing of this stuff. |
| 08:54 | <tobie> | annevk: Pragmatic Thinking and Learning by Andy Hunt talks about this quite a bit iirc. |
| 10:19 | <JakeA> | Domenic: http://output.jsbin.com/hiwokuy/quiet - I've been playing with FileReader vs Response for reading large 900mb files from disk. Turns out response + streams is way more efficient. So, I guess we're all doing something right. |
| 10:19 | <JakeA> | Domenic: http://jsbin.com/hiwokuy/edit?js,console,output is probably a better view |
| 10:25 | <annevk> | JakeA: it's great that we're more efficient, but I'd love to know why and if that's true across browsers |
| 10:25 | <annevk> | JakeA: because in principle it seems like it should be fairly close |
| 10:26 | <JakeA> | annevk: Yeah, it might be highlighting an issue with FileReader in Chrome more than anything. It seems to get slower as it goes on |
| 10:28 | <JakeA> | I wonder if it's rebuilding .result on every progress event or something |
| 10:29 | <JakeA> | The spec is kinda hand-wavey when it comes to allocation of memory |
| 10:30 | <annevk> | JakeA: oh yeah, it seems like result just keeps getting bigger |
| 10:30 | <annevk> | JakeA: which means new object each time given that it's either a string or buffer |
| 10:31 | <annevk> | JakeA: wow, can't believe they just copied that from XMLHttpRequest's responseText |
| 10:31 | <annevk> | JakeA: really hope that isn't true |
| 10:35 | <JakeA> | agreed, espeically as size is known |
| 11:27 | <annevk> | smaug: how does about:blank work? |
| 11:27 | <annevk> | smaug: can I navigate an about:blank document to about:blank? |
| 11:27 | <annevk> | smaug: if I navigate an initial about:blank document to about:blank, is it still initial? |
| 11:29 | <smaug> | hmm hmm |
| 11:29 | <smaug> | if you navigate initial about:blank to anything, the latter document won't be initial anymore |
| 11:29 | <smaug> | but does navigating about:blank to about:blank work |
| 11:30 | <smaug> | it probably does with iframes |
| 11:30 | <smaug> | hsivonen should know all about about:blank :) |
| 11:30 | <annevk> | I think hsivonen gave up and started working on encoding_rs instead |
| 11:32 | <annevk> | smaug: different question, is session history tied to the tab group in Gecko? |
| 11:33 | <mkwst> | annevk: Judging from the explosion in my github inbox, I apparently owe you some responses about link targeting. |
| 11:34 | <smaug> | annevk: session history and tab group? no |
| 11:34 | <smaug> | quite different concepts |
| 11:34 | <mkwst> | annevk: Is there a central question I can answer, or do I need to sit down and read through threads to page context back in? :) |
| 11:34 | <annevk> | mkwst: yeah, that would help, though I also encounter lots of legacy pings to you that went unanswered |
| 11:34 | <smaug> | I mean, tab group may contain several top level browsing contexts |
| 11:34 | <annevk> | mkwst: there's no central question, there's lots of questions |
| 11:34 | <smaug> | session history is per top level browsing context |
| 11:34 | <mkwst> | annevk: Yup. Which is why I'm trying to follow up on them now. |
| 11:35 | <annevk> | mkwst: the browsing context name is probably the most interesting |
| 11:35 | <annevk> | smaug: okay |
| 11:35 | <mkwst> | Ok. None of this has been top-of-mind recently, but I'll try to give you reasonable feedback quickly. |
| 12:26 | <hsivonen> | annevk: https://searchfox.org/mozilla-central/source/testing/web-platform/tests/encoding/iso-2022-jp-encoder.html#16 thinks that U+FF90 encodes in the JIS X 0208 state of ISO-2022-JP, and Gecko with uconv passes |
| 12:26 | <hsivonen> | annevk: the spec disagrees |
| 12:26 | <hsivonen> | annevk: what might the story be here? |
| 12:27 | <hsivonen> | fun times that the test writer calls this "basics" |
| 12:30 | <hsivonen> | oops. I take back the part about uconv passing |
| 12:31 | <hsivonen> | still, what's the deal with that test case? |
| 12:32 | <annevk> | hsivonen: possibly fallout of https://www.w3.org/Bugs/Public/show_bug.cgi?id=27256? |
| 12:34 | <annevk> | hsivonen: I'm somewhat surprised this hasn't come up until now |
| 12:35 | <annevk> | hsivonen: it does seem like https://github.com/whatwg/encoding/commit/19b0ebf0e48c3a607ab7623b5b272642dd59d6e7 ended up removing Katakana support from the encoder and I'm not sure if that was intentional |
| 12:36 | <annevk> | hsivonen: how does FF90 encode inside jis0208 though? |
| 12:45 | <JakeA> | annevk: hah, https://bugs.chromium.org/p/chromium/issues/detail?id=674903 FileReader.readAsArrayBuffer() - Reading large files causes memory leak |
| 12:52 | <annevk> | JakeA: no idea how we prioritize those kind of bugs in Firefox, but those are the kind of reasons folks go native |
| 12:53 | <annevk> | JakeA: not being able to process 10 GiB in a browser in 2017, who'd have thought |
| 12:53 | <annevk> | JakeA: I'm really glad the memory-conservative approach for fetch() won out now though |
| 12:53 | <wanderview> | annevk: we prioritize memory leaks pretty high |
| 12:54 | <JakeA> | annevk: As in stream consuming? Yeah, it seems silly that we considered anything else |
| 12:54 | <annevk> | JakeA: yeah, requiring explicit clones |
| 12:59 | <wanderview> | annevk: alex scolded me about requiring explicit clones on twitter recently... https://twitter.com/slightlylate/status/850819777022967808 |
| 12:59 | <wanderview> | or maybe it was more about the form of clone |
| 13:00 | <wanderview> | I dunno, he seems unhappy with the current state |
| 13:00 | <annevk> | wanderview: yeah, I think he's wrong |
| 13:00 | <annevk> | wanderview: he did indeed argue against it |
| 13:10 | <JakeA> | I'm pretty certain we made the right choice |
| 13:12 | <JakeA> | annevk: fwiw, the filereader route in Firefox is fast, but reader.result is null during progress events which seems wrong http://output.jsbin.com/yazetoy/quiet |
| 13:13 | <annevk> | JakeA: ah okay, it seems better than a giant memory hole though |
| 13:13 | <wanderview> | JakeA: I'll file a bug and CC baku |
| 13:13 | <annevk> | JakeA: because if you want to return intermediate results, there's no way to do that with the current API and not have a giant memory hole |
| 13:13 | <annevk> | JakeA: I think I'd argue we should align the world with Firefox |
| 13:13 | <JakeA> | annevk: oh yeah, if we're playing top browser trumps then Firefox is winning |
| 13:14 | <JakeA> | annevk: hmm, I wonder if Chrome is creating a new buffer per progress… testing |
| 13:15 | <annevk> | JakeA: you have to, they're immutable just like strings |
| 13:15 | <wanderview> | annevk: well, you have to make a new wrapper... the underlying memory could be a fixed buffer, no? |
| 13:15 | <annevk> | JakeA: could be the same backing data, but that'd be a pretty unique implementation strategy for ArrayBuffer just for FileReader |
| 13:15 | <annevk> | wanderview: ^ |
| 13:16 | <JakeA> | annevk: I thought the best course would be to allocate a buffer for the blob's size, then update the buffer during progress events |
| 13:16 | <annevk> | wanderview: I basically don't think anyone has done that work |
| 13:16 | <JakeA> | annevk: So the array buffer would be the total size in the first progress event, but only .loaded bytes would be written to it |
| 13:17 | <annevk> | JakeA: interesting, could work |
| 13:17 | <annevk> | JakeA: doesn't work for the string version though |
| 13:17 | <JakeA> | oh yeah the string version is screwed |
| 13:17 | <annevk> | (though for strings JavaScript engines do have many types to chose from, so optimizations might be possible) |
| 13:18 | <Domenic> | It'd have to be copy on write if you did distinct wrappers with same underlying memory. |
| 13:18 | <annevk> | Good point |
| 13:18 | <annevk> | And all your fast access optimizations are gone |
| 13:18 | <annevk> | Gets complicated fast |
| 13:19 | <JakeA> | Yeah, Chrome creates a new buffer per progress |
| 13:19 | <annevk> | JakeA: given it's a largely legacy API I'd recommend updating the spec to align with Firefox |
| 13:19 | <JakeA> | Domenic: I'm not sure what that means… wouldn't I be able to new Uint8Array(buffer, 0, progressEvent.loaded) without slowing things down? |
| 13:20 | <annevk> | JakeA: Domenic was replying to wanderview's suggestion |
| 13:20 | <JakeA> | ah soz |
| 13:20 | <Domenic> | I'm not sure it's legacy until we have a good replacement |
| 13:21 | <Domenic> | blob.stream() FTW |
| 13:21 | <JakeA> | Domenic: new Response(file) works today |
| 13:21 | <annevk> | new Request(file).body works tomorrow |
| 13:21 | <wanderview> | JakeA: which conveniently removes the progress events |
| 13:21 | <Domenic> | Ah right it's coming back to me now |
| 13:21 | <JakeA> | wanderview: well, you can use streams for that |
| 13:22 | <wanderview> | I live in a world without streams |
| 13:22 | <JakeA> | :D |
| 13:23 | <JakeA> | I'd like blob to take on .body and .json, .text, maybe some of the others |
| 13:23 | <JakeA> | Like fetch |
| 13:23 | <JakeA> | But I'd settle for stream() |
| 13:26 | <annevk> | Yeah, .body and .json() would make slightly more sense to me |
| 13:26 | <wanderview> | JakeA: can you make your jsbin into a WPT test? I don't see anything that does progress+result: https://github.com/w3c/web-platform-tests/tree/master/FileAPI |
| 13:26 | <annevk> | Although maybe it's a little different since you can consume it multiple times |
| 13:27 | <wanderview> | I dunno... seems like it would be nicer to expose blob.stream and then have StreamToJSON(), StreamToText(), etc helpers |
| 13:27 | <JakeA> | wanderview: I'll put it on my TODO list, but I should be getting back to I/O slides. I'm totally procrastinating. I wish there was a jsbin style way to submit web platform tests :D |
| 13:28 | <JakeA> | I reckon we'd get way more contributions if there was |
| 13:28 | <wanderview> | JakeA: I'll write a gecko bug for now (I stopped before when annevk said he liked firefox) |
| 13:28 | <JakeA> | fwiw the spec isn't clear how progress events should work. And Chome's interpretation is causes major problems |
| 13:29 | <wanderview> | ok, maybe a spec issue thne |
| 13:29 | <JakeA> | wanderview: well, I agree with annevk, I don't think it's clear that Firefox is in the wrong |
| 13:29 | <annevk> | I'd just file an issue against File API |
| 13:29 | <annevk> | and have them deal with it |
| 13:29 | <wanderview> | I like that solution ^^^ especially since I don't have to do anything |
| 13:29 | <annevk> | I can do it I guess |
| 13:29 | <wanderview> | oh, I misread "I'd" as "I'll" |
| 13:30 | <JakeA> | I'll do it |
| 13:30 | <wanderview> | I need Domenic's extension to find the correct File API spec for me... |
| 13:30 | <JakeA> | I'm writing a Chrome bug anyway |
| 13:30 | <annevk> | JakeA: wanderview: https://github.com/w3c/FileAPI/issues/79 |
| 13:30 | <wanderview> | JakeA: doesn't google have some kind of mechanical turk way of turning jsbin's into WPT tests via interns? |
| 13:30 | <tobie> | JakeA: a tool to simplify test submission by devs was already in discussion in the test the web forward days |
| 13:31 | <tobie> | JakeA: still think it's a great idea |
| 13:32 | <wanderview> | having spec changes paired with WPT tests has been a huge benefit, IMO |
| 13:32 | <JakeA> | tobie: Yeah, a jsbin type thing but supports the serverside stuff too. Then a button to convert it into a PR |
| 13:32 | <wanderview> | moar WPT tests |
| 13:32 | <annevk> | hsivonen: let me know if you want me to investigate that iso-2022-jp thing; I can file an issue against whatwg/encoding |
| 13:32 | <tobie> | yup. PR conversion is actually rather easy to do for simple cases. |
| 13:34 | <annevk> | hsivonen: I wrote that test btw |
| 13:34 | <annevk> | hsivonen: per https://github.com/w3c/web-platform-tests/commits/master/encoding/iso-2022-jp-encoder.html |
| 13:44 | <annevk> | Hmm, I wanted to get to error documents today |
| 13:44 | <annevk> | But about:blank research won |
| 14:32 | <jugglinmike> | Domenic: I'm trying to find justification for a Chromium test: https://chromium.googlesource.com/chromium/src/+/master/third_party/WebKit/LayoutTests/http/tests/serviceworker/immutable-prototype-serviceworker.html |
| 14:33 | <jugglinmike> | which uses https://chromium.googlesource.com/chromium/src/+/master/third_party/WebKit/LayoutTests/http/tests/serviceworker/resources/immutable-prototype-serviceworker.js |
| 14:33 | <jugglinmike> | I thought this might fall under WebIDL, but I can't see anything there |
| 14:33 | <jugglinmike> | for instance, there's this line: "Unless otherwise specified, the [[Extensible]] internal property of objects defined in this section has the value true." |
| 14:34 | <Domenic> | jugglinmike: https://heycam.github.io/webidl/#interface-prototype-object second to last sentence |
| 14:34 | <Domenic> | And https://heycam.github.io/webidl/#platform-object-setprototypeof |
| 14:35 | <jugglinmike> | oh geez |
| 14:35 | <jugglinmike> | Forgive me--that's so obvious. My problem is that I've been looking at this document https://www.w3.org/TR/WebIDL-1/#interface-prototype-object |
| 14:35 | <jugglinmike> | where [[SetPrototypeOf]] is not referenced |
| 14:36 | <wanderview> | jugglinmike: someone once told me "TR" stands for trash... best to look at the editors drafts |
| 14:36 | <jugglinmike> | haha, noted |
| 14:38 | <Domenic> | More points in favor of my extension |
| 14:39 | <Domenic> | (my not-yet-existing extension: https://twitter.com/domenic/status/859235099187040257 ) |
| 14:40 | <wanderview> | Domenic: its been 2.5 days... no extension yet? |
| 17:50 | <annevk> | rbyers: https://github.com/whatwg/html/issues/1826 |
| 18:12 | <rbyers> | annevk: Damn, sorry I missed that. |
| 18:15 | <jochen__> | any advice how I'd best write tests for https://github.com/whatwg/html/pull/2623 ? |
| 18:15 | <jochen__> | specifically, what's the standard way for wpt to check that a download was succesful |
| 19:31 | <annevk> | jochen__: manual tests I guess |
| 19:31 | <annevk> | jochen__: prolly worth filing a wpt issue to ask for automation |
| 19:31 | <annevk> | jochen__: hopefully webdriver support will come eventually |
| 22:04 | <zcorpan> | TabAtkins: could https://rawgit.com/tabatkins/bikeshed/master/docs/index.html#metadata-default-highlight apply only to <pre> and <xmp>, but not <code>? |
| 22:05 | <zcorpan> | TabAtkins: I tried using this in Geometry APIs but it is applied to <dfn><code>... which is not what I want |
| 22:38 | <TabAtkins> | Sure, file an issue. |
| 22:39 | <TabAtkins> | Btw, you can access the docs at tabatkins.github.io/bikeshed/ |