WHATWG
2022-12-14
plaintext logs
prev next
source on github
00:16
<Domenic>
I don't know what ReadableWritablePair is, but indeed, any { readable, writable } object works with pipeThrough().
00:16
<Andreu Botella>
That's the dictionary type name for {readable, writable}
00:17
<Andreu Botella>
https://streams.spec.whatwg.org/#dictdef-readablewritablepair
00:17
<Domenic>
Ah, so it is.
09:19
<annevk>
sideshowbarker: please don't, as Domenic mentioned I hit a rather unusual case.
10:02
<sideshowbarker>
sideshowbarker: please don't, as Domenic mentioned I hit a rather unusual case.
Ah ok, I hadn't managed to make time yet to look anyway :)
11:31
<krosylight|out-until-Jan-6>

A stream question:

var readableStream = new ReadableStream({
  start(controller) {
    controller.enqueue(new Uint8Array(40));
  },
  type: 'bytes'
});
var [branch1, branch2] = readableStream.tee();
reader1 = branch1.getReader({mode: 'byob'});
console.log(await reader1.read(new Uint8Array(8)))
reader2 = branch2.getReader({mode: 'byob'});
console.log(await reader2.read(new Uint8Array(12)))

The first call obviously gets a view with length 8, and surprisingly the second call also gets a length 8 one instead of 12. Is this expected? If then what should a dev do to get 12-length view for the second call?

11:32
<mztea9281>
krosylight|out-until-Jan-6:
11:40
<krosylight|out-until-Jan-6>
Hmm, Blink somehow fails to get byte stream from tee() while Node.js has the same behavior with Gecko
12:43
<Domenic>
Blink indeed is still working on implementing https://github.com/whatwg/streams/commit/cada8129edcc4803b2878a7a3f5e1d8325dc0c23
12:44
<Domenic>
That behavior is expected because the source readableStream has already sliced out 8 bytes and handed that chunk to each branch
12:44
<Domenic>
If you want 4 more bytes you'd need to request them. (That will then slice another 4-byte chunk for each branch.)
12:45
<Domenic>
https://github.com/whatwg/streams/pull/1145 would be helpful for that, as it would aggregate the 8-byte and 4-byte chunks for you
12:46
<Domenic>
If Firefox is interested in implementing that I believe we can merge it.
12:51
<jgraham>

Hmm, so I think I thought that browsing context groups were 1:1 with agent clusters, but it seems like they aren't.

More concretely what I want to know is "what's the set of browsing contexts that can access each other's DOM nodes?". Specifically for WebDriver-BiDi we want to be able to vend a reference to a Node that's usable in any context where that Node is reachable, but not outside of that context (so e.g. I should be able to write a BiDi script that gets a reference to, say, window.opener.body in some Window, assuming that's permitted by the security policy, and then use that reference in the opener Window to get the <body> element).

14:38
<annevk>
jgraham: that would be all the browsing contexts belonging to a single agent cluster that belongs to a browsing context groups, though that gives you "can potentially access" (as some of those might only be same origin-domain once you use document.domain)
14:40
<annevk>
jgraham: https://docs.google.com/presentation/d/1hi4gH7pJPHsg_hnIj77XN_ce54HIaNUnBLenVwohFVo/edit#slide=id.g5641ecbac9_0_0 and slide 13 give an overview (related slides have approximate definitions)
15:28
<jgraham>
Hmm, that seems distressingly complex. So given node and document, is there an easy way to tell if document is reachable from node's Document?
15:36
<annevk>
jgraham: maybe through IsPlatformObjectSameOrigin? Though that feels a bit hack-ish
15:37
<annevk>
jgraham: I guess you can compare node's node document's surrounding agent's agent cluster with document's surrounding agent's agent cluster? Again, this gives you potentially reachable, not reachable.
15:45
<jgraham>
Yeah, so IsPlatformObjectSameOrigin doesn't work for mechanical reasons at least (it's not clear that Current Realm is well defined when you're calling from WebDriver, so you'd need to write an equivalent algorithm that takes a realm (or document or whatever) as a parameter).
15:48
<jgraham>
The difference between potentially reachable and reachable also seems relevant; it would be surprising if you could use WebDriver to get an element from document A in document B if that would usually require both A and B to set document.domain.