| 06:25 | <scott_michaud_riv> | Hello! Regarding the FS Living Standard (https://fs.spec.whatwg.org/#files-and-directories) I notice that there's no direct mention of maximum path length. Is that expected to be a non-issue? Or should app developers keep the total nesting of directories below some threshold for cross-platform compatibility? (Crossing fingers that I don't need to keep things under 256/260 chars for MAX_PATH lol.) |
| 10:38 | <Noam Rosenthal> | We're already using this fictional document when navigating a new tab... so it would be a consistent unfortunate way to spec this |
| 10:39 | <Noam Rosenthal> | There are probably clearer ways to describe the desired behavior but I'm not convinced about "easier" |
| 10:41 | <Noam Rosenthal> | We can probably create something like a reserved environment that's not a document to be the fetch client in this case, but I'm not sure it's easier in anyway (or substantially different from an initial about:blank) |
| 10:49 | <Noam Rosenthal> | In any case, the result should be equivalent in the web observable sense |
| 11:03 | <Noam Rosenthal> | I think the other option is actually to have a request client of null. It would have a reserved client created in https://html.spec.whatwg.org/multipage/browsing-the-web.html#create-navigation-params-by-fetching. fetch can work fine without a request client. |
| 11:03 | <Noam Rosenthal> | Looking at chromium code for this, it's kind of more equivalent to what's happening in a UI-initiated navigation |
| 12:39 | <Noam Rosenthal> | Heh in "If r is a navigation request that was explicitly caused by a user’s interaction with the user agent (by typing an address into the user agent directly, for example, or by clicking a bookmark, etc.), then set header’s value to none." https://w3c.github.io/webappsec-fetch-metadata/#sec-fetch-site-header |
| 12:40 | <Noam Rosenthal> | So so far I can't see one place where it matters whether the origin of the navigation request is opaque or the new navigation URL, also service workers don't expose this |
| 16:14 | <annevk> | scott_michaud_riv: not sure. But https://infra.spec.whatwg.org/#algorithm-limits might help. |
| 21:20 | <akaster> | When WebIDL says: N. Return PerformPromiseThen(promise.[[Promise]], onFulfilled, onRejected, newCapability). should the steps actually be: N. PerformPromiseThen(promise.[[Promise]], onFulfilled, onRejected, newCapability). N+1. Return newCapability. ? |
| 21:21 | <akaster> | PerformPromiseThen will return newCapability.[[Promise]] if newCapability is not undefined. but the actual [[Promise]] slot of a PromiseCapability is kind of useless to WebIDL |
| 21:22 | <akaster> | you can't re-wrap it in another PromiseCapability for example |
| 21:30 | <annevk> | akaster: seems likely from what is done elsewhere, though not exactly an expert. You could wait for Domenic but seems reasonable to preemptively file an issue to at least get it clarified if it's intentional. |
| 21:32 | <akaster> | thanks! I'm looking at our implementation of converting JS values to WebIDL Promises and back, and it seems we had quite a lot of confusion about the use of a Promise vs a PromiseCapability back when we wrote that part of the code generator. Cleaning this up is requiring some hard looks at the WebIDL spec. (side yak from implementing https://webassembly.github.io/spec/web-api/#compile-a-potential-webassembly-response, which both takes and returns a Promise<T>) |
| 21:41 | <akaster> | https://github.com/whatwg/webidl/issues/1443 |