| 02:07 | <Domenic> | wanderview: in this case, a large part of the issue is that only in Gecko do these ambiguities cause crashes... so omitting those spec steps does not pose a problem for other browsers, so it's just a matter of superhuman diligence to remember "gecko doesn't have a fallback if you combine the code you're implementing with multiple globals in certain ways". That isn't something you can catch during code review easily. |
| 02:08 | <Domenic> | In other words, it's not a straightforward "the spec says to do X, but X is undefined." |
| 02:09 | <wanderview> | Domenic: I'm not just talking about this global issue |
| 02:10 | <Domenic> | Fair. |
| 04:33 | <hendry> | Are we just missing browser support for input type=date and min? Use case: Age validation https://jsfiddle.net/kaihendry/r97gpgmn/ |
| 07:47 | <JakeA> | annevk: was going to ask tc39 to fast track CancelError or whatever they're calling it, and we'll use it instead of DOMException AbortError. Any objections? |
| 07:48 | <JakeA> | Gives us compatibility with whatever they come up with, if they get anywhere |
| 07:50 | <annevk> | JakeA: I'm not sure |
| 07:50 | <JakeA> | Compatibility as in promises will reject with the same error |
| 07:51 | <annevk> | JakeA: if what they're doing has buy-in from everyone we should just use that I guess |
| 07:51 | <annevk> | JakeA: and not pick bits and pieces |
| 07:53 | <JakeA> | annevk: pretty sure their thing is a year away at least. No discussion of sending signals into workers for instance. Whereas a JavaScript CancelError seems useful in other places, such as streams |
| 07:54 | <JakeA> | If their thing happens, I'm worried about devs having to check for both AbortError and CancelError in promise rejections |
| 07:54 | <JakeA> | And stream errors for that matter |
| 07:54 | <annevk> | JakeA: we'd have to define the serialization/deserialization for any kind of object they come up with |
| 07:54 | <annevk> | JakeA: ECMAScript doesn't cover that |
| 07:54 | <annevk> | JakeA: Domenic has a PR for using "AbortError" in Streams |
| 07:55 | <annevk> | JakeA: do you know what Domenic thinks? |
| 07:55 | <annevk> | JakeA: it also seems rather ugly naming-wise |
| 07:55 | <annevk> | JakeA: having just named everything Abort, or would we swap all that back to Cancel? |
| 07:58 | <JakeA> | annevk: wasn't aware that AbortError was going into streams already. Maybe what I'm worried about would be better fixed with a isAbortError() helper somewhere. |
| 07:58 | <JakeA> | Which would include any new abort/cancel thing tc39 ship |
| 07:58 | <annevk> | JakeA: will they actually ship though? |
| 07:58 | <annevk> | JakeA: I mean, we could object |
| 07:58 | <annevk> | JakeA: it's just a proposal at this point |
| 07:59 | <annevk> | JakeA: I suggest you discuss with Domenic |
| 08:01 | <Domenic> | JakeA: our plan is to ask them to use AbortError. |
| 08:02 | <JakeA> | Domenic: as in DOMException? |
| 08:02 | <Domenic> | Yes. |
| 08:03 | <JakeA> | Huh, ok |
| 08:03 | JakeA | crawls back in his cave |
| 08:06 | <JakeA> | Domenic: are you on travels, or up at silly-oclock? |
| 08:06 | <annevk> | Domenic: it's a little frustrating though that we now have to wait and see again since we were pretty close to shipping abortable fetch |
| 08:06 | <Domenic> | annevk: no waiting, at least, none from us. |
| 08:06 | <Domenic> | Please ship. |
| 08:07 | <Domenic> | We will object to anything that causes shipping delays. |
| 08:07 | <Domenic> | JakeA: 7:30am flight. |
| 08:08 | <JakeA> | Oof |
| 08:08 | <annevk> | Domenic: oh wow, good morning! |
| 08:08 | <annevk> | Domenic: enjoy your extremely long day |
| 08:09 | <Domenic> | Yeah, it was either this or miss Japanese class last night, haha. |
| 08:10 | <Domenic> | Anyway, bbiab |
| 08:55 | <Domenic> | annevk: JakeA: when is aborting fetch landing in the spec, anyway? |
| 08:56 | <JakeA> | Domenic: I'm not sure about the spec, but Mozilla are going to implement based off https://github.com/w3c/web-platform-tests/pull/6484 |
| 08:57 | <annevk> | Domenic: I think JakeA's been busy with other things? |
| 08:57 | <annevk> | Domenic: I've been meaning to look at it to see if there's some kind of language that can work, but haven't made the time thus far |
| 08:58 | <JakeA> | Yeah I'm hoping to get back to fix the test nits later this week. But I think the spec is kinda blocked on finding a language we can agree on. |
| 08:59 | <annevk> | Domenic: fetch being partially async from the main thread and then fetch itself doing async things from the perspective of itself and then the main thread being able to cancel all is just rather hard to wrap my head around still |
| 08:59 | <annevk> | Domenic: we don't really have good language available either for these things, just "in parallel" which is a rather poor primitive |
| 09:00 | <Domenic> | I am not yet convinced "in parallel" is problematic, but happy to defer... I think ideally we should be able to write something that works and iterate later though. |
| 09:05 | <annevk> | Domenic: if inside "in parallel" you use "in parallel" again. How do you message between those? |
| 09:05 | <Domenic> | annevk: it's not allowed to use in parallel from inside in parallel |
| 09:05 | <annevk> | Domenic: how do you message from the main thread to something that happens "in parallel"? |
| 09:06 | <annevk> | Domenic: then it's already not suitable for fetch! |
| 09:06 | <Domenic> | I don't see how |
| 09:06 | <Domenic> | You can still do things concurrently |
| 09:06 | <Domenic> | Just not "in parallel" |
| 09:06 | <annevk> | Domenic: in impls fetch is a thread that itself does other async work, such as reading from disk |
| 09:07 | <Domenic> | Concurrent things can just operate on shared objects |
| 09:07 | <Domenic> | Well, shared infra structures |
| 09:07 | <annevk> | Domenic: what's a concurrent thing? |
| 09:07 | <Domenic> | Two processes taking place concurrently |
| 09:07 | <Domenic> | Like two fetches |
| 09:07 | <Domenic> | We do this all the time |
| 09:07 | <annevk> | Domenic: how is that different from in parallel? |
| 09:08 | <Domenic> | Because "in parallel" is an invocation that takes you from the main thread to the pool of stuff running in parallel to the main thread |
| 09:08 | <Domenic> | If you're already in that pool of stuff you can just do more stuff |
| 09:08 | <annevk> | Domenic: with what language? |
| 09:08 | <Domenic> | "Do X", "Do X without blocking Y", "Also do X"... |
| 09:08 | <Domenic> | Just English suffices |
| 09:10 | <annevk> | Domenic: that seems very imprecise |
| 09:10 | <Domenic> | I mean, it purposefully is, to allow implementations freedom to implement whichever concurrency model or threading choices they want |
| 09:10 | <annevk> | Domenic: it also still doesn't address how the main thread talks to the in parallel pool after it's created |
| 09:10 | <Domenic> | Yeah, that's an interesting one |
| 09:11 | <annevk> | Domenic: I think if we had explicit threads and messaging impls could still do whatever |
| 09:11 | <Domenic> | Currently I think we just queue a task back on the main thread to check some state, before going back to in-parallel |
| 09:11 | <Domenic> | I think it'd be harder to ensure we don't constrain observable things |
| 09:11 | <annevk> | In some cases that would actually be good |
| 09:12 | <annevk> | E.g., it would eliminate some racing stuff with cookies and such |
| 09:12 | <annevk> | Sometimes we need the in parallel stuff to be a queue |
| 09:12 | <Domenic> | I guess I just haven't seen that yet, but you've done this more |
| 09:13 | <annevk> | The idea is partially from Jeffrey Yasskin |
| 09:14 | <annevk> | And also how I'm told storage gets synchronized and updated across the various processes that might need to access it |
| 09:14 | <annevk> | If you just have "in parallel" you get races between processes and you can't really define shared workers or service workers well |
| 09:15 | <annevk> | Those need a "named" thread to keep things in order |
| 09:15 | <annevk> | And so in effect while we're not constraining impls, we're allowing freedom they don't really have if they want something robust |
| 09:16 | <Domenic> | I guess I don't understand why these races are bad, instead of good. Between multiple processes seems like a perfectly fine way to race. |
| 09:17 | <annevk> | Domenic: maybe it's different, it's that the spec can't describe something that has to exist |
| 09:18 | <annevk> | Domenic: you need a central place to ask for service workers |
| 09:18 | <annevk> | Domenic: if that's just "in parallel", it's not really defined |
| 12:23 | <annevk> | JakeA: looking at the Fetch PR again and the Fetch Standard |
| 12:24 | <annevk> | JakeA: we already have language such as "If at any point fetch is terminated with reason reason, run these subsubsteps" |
| 12:24 | <annevk> | JakeA: it seems that only addresses responses, but not requests |
| 12:24 | <annevk> | JakeA: must have been an oversight when adding request ReadableStream |
| 12:25 | <annevk> | JakeA: I think if we just used that language here and there it's probably good enough for v1 |
| 12:25 | <annevk> | JakeA: just make it clear what the observable effects will be of fetch being terminated |
| 12:25 | <annevk> | JakeA: seems okay? |
| 12:26 | <JakeA> | annevk: so we either end up with a single "If at any point fetch is terminated…" set of steps, that has to express all the possible points it could be at, or lots of small "if during these steps the signal aborts…" at the various points where abort is handled differently |
| 12:27 | <JakeA> | I was looking into the latter, but Domenic didn't think it matched how it would be implemented. |
| 12:27 | <JakeA> | I'm happy with the former, it'll just be hand-wavey in terms of references |
| 12:29 | <annevk> | JakeA: I'd like the latter, but I don't want to go down the signal route |
| 12:30 | <annevk> | JakeA: well, except for the signal being "terminate the fetch" |
| 12:32 | <annevk> | JakeA: so rather than invent a new way, just extend the existing technique to cover all cases |
| 12:33 | <JakeA> | annevk: I'm not sure I understand. As in, have steps like "if the fetch is terminated during these steps, run the following steps:" throughout fetch, and make the signal "terminate the fetch:? |
| 12:34 | <annevk> | JakeA: yes |
| 12:35 | <annevk> | JakeA: basically extend what's there now |
| 12:36 | <JakeA> | annevk: but right now there's only one point that says how to terminate right? It's at https://fetch.spec.whatwg.org/#concept-fetch-terminate |
| 12:37 | <annevk> | JakeA: "terminated" is referenced from various places in the algorithm |
| 12:37 | <annevk> | JakeA: e.g., "Wait until all the headers are transmitted or fetch is being terminated with reason reason. If fetch is being terminated, then set response’s termination reason to reason." |
| 12:38 | <annevk> | JakeA: it also errors a response body using that kind of language |
| 12:38 | <annevk> | JakeA: it's just that request bodies are not covered due to oversight |
| 12:38 | <JakeA> | annevk: gotcha. Yeah, that seems like a good way to continue |
| 12:43 | <JakeA> | annevk: https://github.com/whatwg/fetch/pull/523#issuecomment-317725255 are we on the same page? |
| 12:44 | <annevk> | JakeA: yeah, although I want to stop using the substeps language if possible, just have "steps" |
| 12:46 | <JakeA> | cool, cheers! |
| 16:55 | <smaug> | annevk: has all the interesting bits moved from Shadow DOM spec to DOM and HTML ? |
| 17:02 | <annevk> | smaug: I think the main things lacking are focus (but that's always been vague) and maybe some UI events stuff |
| 17:02 | <annevk> | smaug: I guess I should create some kind of tracker issue for the remaining bits |