| 11:59 | <smaug____> | I assume https://html.spec.whatwg.org/multipage/browsers.html#auxiliary-browsing-context means in practice something like there is opener relationship |
| 12:00 | <smaug____> | "are related to" without any linking is a tad vague |
| 12:23 | <annevk> | smaug____: yeah, popups |
| 12:24 | <annevk> | smaug____: including <a target=test> |
| 12:24 | <smaug____> | and noopener is supposed to break that relation? |
| 12:25 | <annevk> | smaug____: noopener causes a new top-level browsing context to be created, which doesn't have the field |
| 12:25 | <annevk> | smaug____: see rules for choosing a browsing context or some such |
| 12:25 | <smaug____> | "the field" ? |
| 12:25 | <annevk> | smaug____: the opener field |
| 12:25 | <smaug____> | right, but https://html.spec.whatwg.org/multipage/browsers.html#auxiliary-browsing-context doesn't talk about that |
| 12:26 | <annevk> | no, that's just at type definition |
| 12:26 | <annevk> | a* |
| 16:37 | <Domenic> | annevk: I assume https://github.com/whatwg/html/pull/5560 (Storage refactor) is not yet ready for review? |
| 16:47 | <annevk> | Domenic: it doesn't actually call into the Storage Standard yet for a bottle map and doesn't clone sessionStorage data across browsing sessions, apart from that I consider it good |
| 16:48 | <Domenic> | Should I wait on those parts, or would it make sense to land in stages? |
| 16:48 | <annevk> | Domenic: I don't think we can land, but if you feel like you can review already that might help |
| 16:48 | <annevk> | Domenic: I hope that given how I layered things those to be fairly incremental commits |
| 17:07 | <annevk> | The one interesting architectural question I noticed is how much tasks we should use when broadcasting. If a bunch of tasks end up running in the same agent, should they be one task? (Not sure if it's observable though as these are event callbacks when the stack is empty. But I guess you can tell if they got interleaved.) |
| 17:07 | <Mek> | I would like to specify some algorithms in terms of streams (have some other spec provide a readable stream to my algorithm, apply some transformations to that, and eventually expose the output of that through some non-stream API). But I'm not sure if this actually makes sense, or if this will be very weird since all the streams algorithm operate on actual javascript objects... |
| 17:10 | <Domenic> | Mek: does the other spec provide a `ReadableStream`, or a conceptual "readable stream"? |
| 17:11 | <Mek> | neither part is written yet, but my idea is that it will provide a conceptual "readable stream". I.e. it'll define some way of producing data. |
| 17:12 | <Domenic> | In that case I would avoid using the Streams Standard machinery, as the JS objects aspects of it will cause you some pain. |
| 17:12 | <Domenic> | We're cleaning that up a bit, but it's still not super-pleasant. |
| 17:12 | <Mek> | hmm, having to reinvent a lot of it will be somewhat painfull as well... |
| 17:12 | <Domenic> | Well, how much would you reinvent? |
| 17:13 | <Domenic> | Like, if this is all behind the scenes, it feels like you could get away without needing too much... |
| 17:14 | <annevk> | Mek: looking at Encoding and see if you could generalize that? |
| 17:14 | <annevk> | I would be willing to help with putting some of that into Infra |
| 17:15 | <annevk> | We've had other requests |
| 17:16 | <Mek> | looking at encoding gave me headaches trying to figure out what exactly it is doing (with streams-within-streams, i.e. every chunk in its encode algorithm is treated as another conceptual stream) :) But yeah, something like that perhaps... |
| 17:16 | <annevk> | Mek: I meant everything in this section: https://encoding.spec.whatwg.org/#terminology |
| 17:17 | <annevk> | Mek: wrapping that in Streams doesn't seem like a concern you have |
| 17:18 | <Mek> | I don't think that quite works for what I want. I really want more of the "pull algorithm" style that streams provide. But I guess I can just have specs provide just the required algorithms rather than an actual stream. |
| 17:18 | <Mek> | (context, trying to define Blob read behavior better; in particular how IndexedDB (or Native File System) provides/invalidates data that can be read via a Blob. |
| 17:21 | <annevk> | Mek: maybe also look into the blob store scoping issue? |
| 17:21 | <Mek> | oh yes, sorry I forgot to reply to that |
| 17:21 | <annevk> | No good ideas for invalidation as I'm not very familiar unfortunately |
| 17:23 | <andreubotella> | Mek: Chunks are not streams. You might be getting confused with how Encoding overloads the term "stream", though. |
| 17:24 | <andreubotella> | There was an issue about renaming it to "token queues" and moving it to Infra, which I thought I could take on, but now I can't find it. |
| 17:25 | <Mek> | andreubotella: yeah, that's what I meant. In the en/decode and enqueue a chunk algorithms, Encoding creates a conceptual stream out of the chunk (where the chunk was a chunk written to the actual WritableStream). And it took me a few readings to figure out there were two stream concepts. |
| 17:25 | <annevk> | andreubotella: be my guest 🙂; https://github.com/whatwg/encoding/issues/180 |
| 17:25 | <andreubotella> | annevk: Oh, right. The title confused me. |
| 17:26 | <andreubotella> | thanks |
| 17:26 | <Mek> | like, a TextEncoderStream is a GenericTransformStream, but it also has a conceptual stream, and those are unrelated :) |
| 17:26 | <annevk> | andreubotella: although I think initially we should just keep it in Encoding until we have another more serious consumer |
| 17:26 | <andreubotella> | that makes sense |
| 17:27 | <annevk> | Mek: turtles all the way down |
| 17:29 | <andreubotella> | Mek: I'm not as familiar with the stream parts of Encoding as with the rest, and that threw me off a bit 😅 |
| 17:35 | <Domenic> | Yeah, encoding is not a paragon of clarity. Renaming will help. |
| 17:36 | <annevk> | Well, I'm not sure I agree with that statement |
| 17:37 | <annevk> | I tend to think it's one of the more polished things we publish, but I'm biased 🙂 |
| 18:04 | <Domenic> | Hmm yeah I think my complaints were misremembering... the problem is more in the fetch/streams interaction. https://github.com/whatwg/fetch/issues/661 |
| 18:05 | <Domenic> | Oh right, but the problem is that encoding operations on "streams", but often specs feed it byte sequences. |
| 18:10 | <andreubotella> | The chunks in Encoding streams are code points for decoding and bytes for decoding. |
| 18:10 | <andreubotella> | The string → "stream" of code points and byte sequence → "stream" of bytes conversion is implicit and perhaps shouldn't be. |
| 18:12 | <Domenic> | It's the opposite direction I'm particularly concerned with |
| 18:13 | <Domenic> | Since I believe encoding feeds things into the "stream"s of code points/bytes incrementally, but specs often expect them to be one-shot strings/byte sequences. |
| 18:16 | <andreubotella> | I guess, since I'm renaming "streams" in encoding#180, I could specify that strings/byte sequences can be converted into "streams" implicitly, but not vice versa. |
| 18:29 | <annevk> | That sounds great; it would also be good to write down what we think we would ultimately want in an issue to keep that in mind as things change |
| 18:31 | <smaug____> | hmm, does wpt have some way to close a tab/window which can't be closed using window.close() ? |
| 19:26 | <annevk> | smaug____: let me know if you find out |
| 19:34 | <jgraham> | smaug____: Not at the moment afaik, although I think it could |
| 19:35 | <smaug____> | ok |
| 21:16 | <jgraham> | smaug____: To elaborate a little, the problem is usually knowing which window to close |
| 21:17 | <jgraham> | WebDriver specifies a way to serialize window handles, but afaik no one supports it yet |
| 21:17 | <jgraham> | So you couldn't trivially do something like testdriver.close(window) |
| 21:18 | <jgraham> | There could be some hack to make it work like adding a property on the window and then cycling through all of them until you find the one where the property exists |
| 21:18 | <smaug____> | right |
| 21:18 | <smaug____> | I was thinking some helper method in window object to forceClose it |
| 21:19 | <jgraham> | Well we can also specify test-only apis of course but it feels like maybe overkill for this case |
| 21:19 | <jgraham> | I keep meaning to figure out how to specify a test-only gc api for wpt |
| 21:19 | <jgraham> | But so far didn't manage |
| 21:19 | jgraham | away |