| 09:12 | <annevk> | The way I see it is that USVString is really a binding layer concern (about how some input maps to a scalar value string), past that layer, it's a scalar value string. Eventually we'll make IDL reflect that better. It's currently wrong for ByteString <> byte sequence I think. |
| 11:35 | <croraf> | One important thing that I didn't solve yesterday. What happens when you put just the plain JS object as the body? |
| 11:37 | <annevk> | croraf: for that specific case, since a string is one of the accepted types, it'll get stringified |
| 11:38 | <croraf> | Can you show me where is that conversion defined in the specs? |
| 11:38 | <croraf> | annevk, |
| 11:38 | <annevk> | croraf: it's in IDL |
| 11:40 | <croraf> | I'm checking this https://fetch.spec.whatwg.org/#fetch-method . This is not a JS fetch method, but an abstraction, right? |
| 11:41 | <croraf> | The JS fetch method is mapped to this abstraction? |
| 11:41 | <croraf> | with some conversions happening during the mapping |
| 11:43 | <annevk> | The JavaScript method is derived from it, per the rules in IDL |
| 11:48 | <croraf> | OK, so the JS method's init object must conform to these rules as per IDL? |
| 11:48 | <croraf> | https://fetch.spec.whatwg.org/#requestinit |
| 11:48 | <croraf> | annevk, |
| 11:49 | <croraf> | That is the body property must conform to this https://fetch.spec.whatwg.org/#bodyinit |
| 11:49 | <annevk> | I'm not sure what you mean by conform |
| 11:50 | <andreubotella> | croraf: WebIDL's conversions will throw if there's no way to convert the JS value to the WebIDL type, but it will first try and cast the value in some way |
| 11:50 | <croraf> | When JS method is implemented in the JS engine it must conform to this interface. |
| 11:51 | <croraf> | andreubotella, ok, and where can i see the rule of casting of JS init value (the second argument of JS fetch method) into BodyInit |
| 11:52 | <andreubotella> | BodyInit is a union type: https://heycam.github.io/webidl/#es-union |
| 11:53 | <andreubotella> | all components of the union except for USVString are WebIDL interfaces, and converting to those will throw if the JS object doesn't implement them: https://heycam.github.io/webidl/#es-interface |
| 11:53 | <croraf> | I guess the plain object is bullet 9 there? |
| 11:54 | <andreubotella> | so all that's left are USVStrings: https://heycam.github.io/webidl/#es-USVString |
| 11:56 | <andreubotella> | right, so the types in BodyInit don't match any of the cases in bullet point 9 |
| 11:56 | <croraf> | First one side question, if I have parent steps and a parent step has children steps, and the children step says, return something. |
| 11:57 | <croraf> | Does the return happen only for children steps, or also the parent steps return? |
| 11:57 | <croraf> | Examples here: https://heycam.github.io/webidl/#es-union |
| 11:58 | <andreubotella> | Usually, it's returning from the algorithm as a whole, unless the parent step talks of the child steps as a function/callback |
| 11:59 | <andreubotella> | sometimes that gets confusing, like with step 5 in https://fetch.spec.whatwg.org/#main-fetch |
| 12:02 | <croraf> | andreubotella, So in https://heycam.github.io/webidl/#es-union when child returns the entire algorithm is terminated? |
| 12:02 | <andreubotella> | right |
| 12:03 | <annevk> | croraf: https://infra.spec.whatwg.org/#algorithm-control-flow (anything that doesn't conform to that is worth filing an issue on) |
| 12:04 | <croraf> | annevk, well, is the algorighm the whole algorithm or the subalgorithm for the step only |
| 12:05 | <croraf> | And yes https://fetch.spec.whatwg.org/#main-fetch is really confusing |
| 12:05 | <croraf> | So in main-fetch 5 only step 5 subalgorithm terminates when one of its children returns. |
| 12:06 | <croraf> | ? |
| 12:07 | <andreubotella> | Step 5 has "set response to the result of running the steps..." |
| 12:07 | <andreubotella> | you can think of "running the steps" as calling a callback |
| 12:12 | <croraf> | Why do you think this is the correct interpretation? |
| 12:15 | <andreubotella> | experience in reading steps, mostly |
| 12:15 | <andreubotella> | s/steps/specs/ |
| 12:15 | <croraf> | yes, this is not optimal. |
| 12:16 | <andreubotella> | feel free to suggest alternatives: https://github.com/whatwg/infra/issues/311 |
| 12:17 | <croraf> | Also the control flow annevk posted is for the WHATWG specs not for the WebIDL that I asked for. |
| 12:17 | <annevk> | croraf: IDL should follow it too |
| 12:17 | <croraf> | ok |
| 12:18 | <andreubotella> | the "algorithm" parts of infra do little more than formalize what was already the standard across WHATWG and W3C specs |
| 12:20 | <croraf> | OK, so because the JS value of plain object doesnt satisfy any of the steps 3-8, the step 9 is entered. |
| 12:20 | <annevk> | there were definitely competing styles and some of that might still be there; Infra was created in part to reduce that |
| 12:20 | <croraf> | Here all are interfaces except BufferSource and USVString. |
| 12:21 | <andreubotella> | BufferSource is itself a union of interfaces, so it's all interfaces except for USVString |
| 12:23 | <croraf> | I'm not so sure that BufferSOurce is a union of interfaces, but lets assume that for now |
| 12:23 | <andreubotella> | https://heycam.github.io/webidl/#common |
| 12:23 | <croraf> | So interface is none of the types defined in 9.1-9.6 |
| 12:24 | <croraf> | These are all types distinct from interface? |
| 12:24 | <andreubotella> | right |
| 12:25 | <croraf> | So which of these types is the USVString? |
| 12:25 | <andreubotella> | none of the substeps in step 9 apply, so you exit the substeps and continue |
| 12:25 | <andreubotella> | eventually you end up in step 13, and here USVString *is* a string type |
| 12:27 | <croraf> | cool |
| 12:27 | <andreubotella> | btw: DOMString (or Infra's "string") is &[u16] (UTF-16), ByteString is &[u8], USVString is &str |
| 12:28 | <croraf> | If you check https://heycam.github.io/webidl/#BufferSource you can see that it can be a wide variety of things |
| 12:29 | <croraf> | I cannot see that any of those is an interface |
| 12:30 | <annevk> | Maybe that should be clarified, but they are interfaces/classes |
| 12:35 | <croraf> | Ok. The conversion of plain object to USVString is done per https://heycam.github.io/webidl/#es-USVString |
| 12:36 | <croraf> | Which is basically a ToString(object) |
| 12:39 | <croraf> | and converted to UTF8 or? |
| 12:39 | <andreubotella> | decoded as UTF-16, with lone surrogates replaced with the replacement character |
| 12:40 | <andreubotella> | like rust's String::from_utf16_lossy |
| 12:40 | <croraf> | The comment below at x:26:37 was a reference to rust? |
| 12:40 | <croraf> | *above |
| 12:41 | <andreubotella> | yeah |
| 12:41 | <croraf> | Let's just clear this last thing out. ByteString are bytes containing UTF-8, DOMString are pairs of bytes containing UTF-16? |
| 12:42 | <andreubotella> | no |
| 12:44 | <andreubotella> | JS's strings and DOMString are &[u16], not necessarily valid UTF-16, but interpreted as such when there's some interpreting needed |
| 12:46 | <andreubotella> | but sometimes WebIDL needs strings that are ASCII only, to send to HTTP for example, and it will cast each number in the &[u16] to a u8 |
| 12:47 | <croraf> | OK. To conclude, that's why i need to manually set Content-Type application/json on plain JS object body. Because otherwiser it will be interpreted as text/plain. |
| 12:49 | <andreubotella> | you don't wanna pass a plain JS object as the body, because String({}) === "[object Object]" |
| 12:49 | <andreubotella> | but yeah, you'd have to set the content-type manually |
| 12:52 | <croraf> | yes, thanks. |
| 12:54 | <croraf> | Something to clear the monotony, HTML spec: the select shouldn't trigger onchange if the same option is clicked? |
| 12:57 | <croraf> | I'll check, but I guess not. I'm using React and a UI library on top of it, so some of these is not conforming :| |
| 13:21 | <croraf> | Yes, indeed even in React the onChange is not triggered if the already selected option is reselected. |
| 13:44 | <croraf> | In short the issue was that the value of select was being set as a number, implicitly converted to string, and when reselect was made the string value was detected as newly selected, causing the change event. |
| 16:25 | <benjamingr__> | Is Node allowed to add additional symbols to its `EventTarget` for inspections/warnings? (like `EventTarget.symbolInspectDepth` and such) |
| 16:25 | <benjamingr__> | We want to add debugging related symbols to `EventTarget` that effect functionality in a non-observable way and I want to make sure we are not violating the spec in doing so. |
| 16:27 | <Domenic> | benjamingr__: no, you cannot add properties to interfaces that are not in the spec... |
| 16:28 | <benjamingr__> | Ok, thanks |
| 16:28 | <benjamingr__> | Wanted to make sure, will quote you on that when blocking the PR :P |
| 16:30 | <Domenic> | In particular https://heycam.github.io/webidl/#create-an-interface-object does not have a step that says "and then add any properties you want" |
| 21:40 | <croraf> | Anyone knows on the highlevel how the youtube video works. I see it has the video HTML element, but I even see that they download any video content through it? |
| 21:41 | <croraf> | I don't see any media request in the devtools network tab, but i see they download the content through xhr. |
| 21:45 | <croraf> | Seems like they somehow prevent the download to happen. For example this is the video element: <video tabindex="-1" class="video-stream html5-main-video" controlslist="nodownload" src="blob:https://www.youtube.com/b5b90a1b-c8c2-4673-9657-1d9c338db209"; style="width: 612px; height: 344px; left: 0px; top: 0px;"></video> |
| 21:46 | <andreubotella> | the url in the src attribute has a blob scheme, not https |
| 21:46 | <andreubotella> | https://w3c.github.io/FileAPI/#url |
| 22:00 | <croraf> | andreubotella, thanks, I was suspecting into that blob, but going through the spec for the video element I arrived to here: https://url.spec.whatwg.org/#concept-url-parser |
| 22:03 | <croraf> | Does the basic url parser just resolve the absolute+relative path? |
| 22:06 | <andreubotella> | the important bit for this in the url parser is step 4, which populates the blob URL entry which is then used from https://fetch.spec.whatwg.org/#main-fetch |
| 22:07 | <croraf> | Yes, that's what I thought, the step 1 does nothing important |
| 22:08 | <croraf> | So you want to say that the browser stores a "blob dictionary"? How can I inspect it or add stuff to it? |
| 22:08 | <andreubotella> | https://w3c.github.io/FileAPI/#creating-revoking |
| 22:10 | <andreubotella> | you can't inspect it other than seeing if a particular blob URL resolves |
| 22:10 | <andreubotella> | I suppose that's because browsers have leeway in deciding when to garbage collect the blobs, and you don't want developers to start depending on some browser's current behavior |
| 22:11 | <croraf> | OK, so how can I find into what this blob:https://www.youtube.com/494cb097-fd0f-496a-be3f-fcc04b5218e3 resolves |
| 22:12 | <croraf> | I tried: window.URL.revokeObjectURL('https://www.youtube.com/494cb097-fd0f-496a-be3f-fcc04b5218e3';) |
| 22:13 | <croraf> | in the console. and the video element's src with this blob is NOT in any iframe, but in the main window frame. |
| 22:13 | <croraf> | got undefined. |
| 22:14 | <andreubotella> | URL.prototype.revokeObjectURL always returns undefined |
| 22:14 | <andreubotella> | since you have a URL, you can try and fetch it or open it in a new tab |
| 22:14 | <croraf> | did i destroy the mapping with that? |
| 22:14 | <andreubotella> | yeah |
| 22:15 | <croraf> | but isn't there an api to see into what this resolves? |
| 22:15 | <andreubotella> | that'd break encapsulation, wouldn't it? |
| 22:19 | <croraf> | I can add an object to the blobstore with window.URL.createObjectURL(...) and retrive it by parsing the URL? |
| 22:19 | <andreubotella> | by fetching the URL, rather |
| 22:20 | <andreubotella> | that's the whole point of URL.createObjectURL(...) |
| 22:21 | <andreubotella> | there are many older APIs that will only take a URL rather than a Uint8Array or a ReadableStream, and this is a compatibility layer |
| 22:21 | <croraf> | In the context of the "media HTML elements" the parsing is done prior to fetching. |
| 22:22 | <andreubotella> | if you're trying to fetch a URL, you ofc need to parse it first |
| 22:22 | <croraf> | as a separate algorithm |
| 22:22 | <andreubotella> | but the parsing doesn't make the underlying blob or MediaStream available to any other API |
| 22:22 | <andreubotella> | fetching does |
| 22:22 | <andreubotella> | or the data inside it, rather |
| 22:23 | <croraf> | So parsing can be done only internally within specific APIs, like fetch() or "media elements" |
| 22:24 | <andreubotella> | sigh |
| 22:24 | <andreubotella> | URL's "blob URL entry" is essentially a private field |
| 22:25 | <andreubotella> | it's not available to the URL JS API, and I think only the File APIs and fetch use it |
| 22:25 | <andreubotella> | for everything else, the way to get the blob's data is by fetching the URL |
| 22:33 | <croraf> | andreubotella, thanks. I now created a URL with a blob content. Fetched it with fetch('blob-reference') and read its content. Kind of cool. |
| 22:35 | <croraf> | But for some reason I cannot fetch the blob src from the video element. How come? |
| 22:36 | <andreubotella> | maybe because it doesn't have a video content type? |
| 22:36 | <andreubotella> | I don't know |
| 22:36 | <andreubotella> | youtube is probably using MediaSource with the URL.createObjectUrl(...) API, but I've never used it or dived into the spec |
| 22:36 | <Mek> | at least in chrome blob urls created from a MediaSource instead of a Blob can't be fetched... |
| 22:37 | <croraf> | It says net::ERR_FILE_NOT_FOUND |
| 22:38 | <Mek> | yeah, in chrome blob URLs refering MediaSource objects are treated separately, and only can be resolved by code that specifically looks for MediaSource objects... (and only in the same process as where the URL was created) |
| 22:40 | <croraf> | Yes, indeed I try: window.URL.createObjectURL(new MediaSource()) and await fetch("blob:https://www.youtube.com/b4e0b59c-6711-49d8-8c23-9a924060df1a";) on it gives ERR_FILE_NOT_FOUND |
| 22:44 | <croraf> | Two sidenotes. 1. blob is kind of unfortunate prefix and store name, cause it can contain a MediaSource also per w3c FileAPI. 2. MDN https://developer.mozilla.org/en-US/docs/Web/API/URL/createObjectURL says it can also contain a File object. |
| 22:45 | <andreubotella> | File is a subclass of Blob |
| 22:46 | <croraf> | Oh, I see. MDN should be slightly corrected though then. |
| 22:48 | <andreubotella> | And I suspect that originally only Blobs were supported and MediaSource was added later on |
| 22:48 | <andreubotella> | that kind of thing happens a lot |
| 22:50 | <croraf> | FF does also throw an error https://pasteboard.co/Jzaw4wR.png |
| 22:51 | <croraf> | Is this then alligned with the specification? |
| 22:51 | <Mek> | I think so, yes. https://fetch.spec.whatwg.org/#scheme-fetch says "[if] blob is not a Blob object, then return a network error. " |
| 22:54 | <croraf> | cool |
| 23:04 | <andreubotella> | but if I'm reading the media loading parts of the HTML spec correctly (and assuming that a URL's "object" is an older name for the blob URL entry), <video> should be able to handle MediaSource URLs |
| 23:05 | <croraf> | Yes, video is using them likely. |
| 23:05 | <croraf> | But I'm trying to see if I can get this MeidaSource directly |
| 23:06 | <croraf> | I tried (optimistically :D) new MediaSource('blob:...') but dont think I got anything :D |
| 23:06 | <croraf> | I got an empty MediaSource |
| 23:07 | <croraf> | I dont think I can get the underlying souce either through the video element |
| 23:17 | <croraf> | I think in the case of this video element, the video resource is resolved as following: |
| 23:19 | <croraf> | 1. https://html.spec.whatwg.org/multipage/media.html#concept-media-load-algorithm 9.attribute is entered where urlRecord is a resolved MediaSource object |
| 23:19 | <croraf> | in bullet 2 of 9.attribute |
| 23:21 | <croraf> | In bullet 5 of 9.attribute a resource fetch algorithm is called with URL record whose object is a media provider object (a MediaSource), so the mode is set to local. |
| 23:28 | <croraf> | And current media resource is set to the underlying MediaSource object, and the local mode branch of https://html.spec.whatwg.org/multipage/media.html#concept-media-load-resource is processed. |
