| 00:02 | <croraf> | I mean, I was reading today that in ECMAScript if the onrejected is not provided there is a default happening. |
| 00:03 | <croraf> | Probably there is a default behavior happening in WebIDL also. |
| 00:04 | <croraf> | I mean actually this "PerformPromiseThen" in the last bullet of "react to a promise" https://heycam.github.io/webidl/#dfn-perform-steps-once-promise-is-settled is actually an Operation from ECMAScript |
| 00:06 | <croraf> | So it is the same as "promise.then(resolveFunction, undefined)" when promise gets rejected, that means the default behavior is invoket. |
| 00:07 | <andreubotella> | no, the subitems in step 3 are a spec-level algorithm that gets converted into a ES-level function on step 4, and that is passed to PerformPromiseThen |
| 00:09 | <croraf> | OK, this is invoked https://tc39.es/ecma262/#sec-createbuiltinfunction with (undefined, <<>>) |
| 00:10 | <andreubotella> | whenever you see "steps" in a web spec, you can probably substitute that with function/closure |
| 00:11 | <andreubotella> | onRejectedSteps is the algorithm in the substeps, not its return value |
| 00:12 | <croraf> | Aha, it is a list of steps to be performed later |
| 00:12 | <croraf> | A callback. |
| 00:13 | <andreubotella> | right |
| 00:13 | <croraf> | This is so spaghetti, my head hurts :D |
| 00:14 | <andreubotella> | interacting with ES internals sometimes gets like that, and especially for promises :) |
| 00:16 | <croraf> | So what happens then. The promise gets rejected with let's say TypeError (during byte reading). |
| 00:25 | <croraf> | const result = response.text() = readAllBytesPromise.then(resolve, onRejected) |
| 00:26 | <croraf> | The promise gets rejected and onRejected is called with TypeError argument. The result is another promise which gets resolved with the return of onRejected function. |
| 00:29 | <croraf> | The function 3. in https://heycam.github.io/webidl/#dfn-perform-steps-once-promise-is-settled returns undefined. |
| 00:29 | <croraf> | So the result of the entire operation is a promise that gets resolved with undefined. |
| 00:30 | <croraf> | This is what you said 45 min ago. |
| 00:30 | <croraf> | OK, go to sleep now. Bye. |
| 08:24 | <noamr> | Good morning annevk! https://github.com/whatwg/html/pull/5574/files has been updated with your previously requested changes, for when you get a chance |
| 08:39 | <annevk> | noamr: I'll have another look in a bit |
| 08:40 | <noamr> | thanks! |
| 08:40 | <annevk> | MikeSmith: Domenic: now that you have made these major changes to Wattsi, I'm wondering if we can change <span> to <a> and data-x to lt... |
| 08:40 | <andreubotella> | yes please |
| 08:40 | <annevk> | MikeSmith: Domenic: making the source even more similar to Bikeshed would be quite nice |
| 09:57 | <MikeSmith> | annevk: yea we can do that |
| 09:57 | <MikeSmith> | all |
| 09:58 | <MikeSmith> | could have done it all in those same HTML/Wattsi commits, but seemed better to get those landed first |
| 09:59 | <annevk> | baby steps |
| 10:00 | <MikeSmith> | yeah, especially with a patch as big as that spec patch was — one problem was that any time almost any other commit got merged to master, I needed to rebase that whole patch |
| 10:00 | <MikeSmith> | ..which was a bit troublesome and also error-prone |
| 10:01 | <MikeSmith> | I guess <span> to <a> and data-x to lt will be big patches too |
| 10:03 | <annevk> | MikeSmith: yeah, I don't know how feasible it is to write a script that does the transformation, but that might be worth doing given the rebasing |
| 10:20 | <croraf> | andreubotella, have you maybe verified my/our conclusion? Is it a bug in the fetch and/or WebIDL specs? |
| 10:22 | <andreubotella> | croraf: since the note to that algorithm says it's equivalent to Promise.prototype.then, and it seems to be used elsewhere as if it's equivalent, I'd say that's a bug in WebIDL |
| 10:22 | <andreubotella> | I'll look at it again later and file the issue |
| 10:25 | <croraf> | andreubotella, cool |
| 12:32 | <noamr> | thanks for the review annevk, already applied/commented/resubmitted :) |
| 13:27 | <Domenic> | annevk: MikeSmith: I'm unsure about data-x -> lt since it won't work like Bikeshed does since Bikeshed contains cross-linking. |
| 13:28 | <Domenic> | Also we wouldn't want to turn what are currently data-x into visible-to-the-external-world data-lt="" |
| 13:29 | <Domenic> | s/Bikeshed contains cross-linking/Bikeshed does cross-spec linking/ |
| 14:45 | <Domenic> | annevk: thoughts on https://github.com/heycam/webidl/pull/883#issuecomment-692972245 ? |
| 14:51 | <annevk> | Domenic: that looks about right, though I haven't thought about this in the context of the cross-origin isolated permission/capability |
| 14:52 | <annevk> | Domenic: good point about lt; I guess we should do <a> first and then figure out whether we want to stop using data-x or not |
| 21:26 | <Domenic> | Anyone know a better page than https://developer.mozilla.org/en-US/docs/Web/API/Document/domain for explaining document.domain and its evilness? The context is writing a web-developer-facing article about origin isolation and how using it will disable document.domain. |