01:44 | <Domenic> | One day I will be able to merge an editorial PR to a bikeshed spec... |
01:44 | <Domenic> | Oh hey it's a 500 error this time instead of a {{Window}} error, that's new at least. |
01:45 | <Domenic> | annevk: maybe we should move off of depending on api.csswg.org for Bikeshed, and locally install it on GitHub actions instead. I'll send a spec-factory PR and see what you think... |
02:00 | <aja> | plinss' csswg.org DB migration still underway? |
03:59 | <Domenic> | PendingGetBeacon/PendingPostBeacon, or PendingGETBeacon/PendingPOSTBeacon? Hmm. |
04:03 | <Domenic> | I guess "GET" is not an initialism so probably "PendingGetBeacon" is best... |
04:59 | <Peter Linss> | DB server on csswg.org was being migrated this evening, server was down for a while. Should have normal service now. (should be better than the recent 'normal') |
06:09 | <annevk> | Domenic: historically I didn't like that because I thought it meant that we had to download and install Bikeshed for each build |
06:10 | <Domenic> | There is some cache thing but it might only work if there's a requirements.txt file... I didn't really want to try it. |
06:10 | <annevk> | I see, it just seems very wasteful to do it this way |
06:10 | <Domenic> | I should check some of the W3C specs that download and install Bikeshed each time and see how long that takes |
06:11 | <Domenic> | I mean to be fair we're downloading and installing all of Python each time, it's not like Bikeshed is that much more comparatively :) |
06:12 | <Domenic> | It seems to take ~17 seconds: https://github.com/w3c/IndexedDB/actions/runs/3063414506/jobs/4945465758#step:3:391 |
06:14 | <Peter Linss> | Another option is to have a GH action that periodically builds a custom docker image with bikeshed and the latest data, then just use that image in your actions |
06:14 | <Peter Linss> | https://github.blog/changelog/2020-09-24-github-actions-private-registry-support-for-job-and-service-containers/ |
06:15 | <Peter Linss> | In theory we could build and serve that image from the csswg.org server (if needed) |
06:17 | <Peter Linss> | (ideally I'd like to have such an image and a k8s cluster to generate all the specs in parallel) |
06:17 | <annevk> | Domenic: oh we are? Why is that? Bah. |
06:18 | <annevk> | I guess I was kinda naΓ―ve in thinking that GitHub would have things locally for things you list statically in the configuration file |
06:21 | <Domenic> | Well that must be what's going on under the hood because setup-python action takes less than 1 second |
06:21 | <Domenic> | Probably it's preinstalled on all the builders already, maybe setup-python just symlinks something |
06:22 | <annevk> | Okay good :-) |
06:33 | <Domenic> | annevk: while I have you, would love to get this merged. https://github.com/whatwg/fetch/pull/1469#issuecomment-1262513703 . I think I addressed your comment to look at things more closely. |
06:40 | <annevk> | Domenic: so what's weird is that we invoke "process response" but the data isn't final yet; and typically we wouldn't reveal the data until all redirects are followed; does that make sense? |
06:40 | <Domenic> | Hmm, I think I see... let me work through the flow |
06:41 | <annevk> | Domenic: I do see your point that it makes sense to hold on to the data given that's what we already do, but currently it wouldn't be exposed at this intermediate point |
06:41 | <Domenic> | Well right now the spec is broken ever since the move to callbacks |
06:41 | <Domenic> | You used to call fetch, get back an intermediate response, and then call HTTP-redirect fetch with that intermediate response |
06:41 | <Domenic> | Now fetch does not return a response, but HTTP-redirect fetch still expects one |
06:42 | <Domenic> | So you'd have to do something like having your processResponse (which gets the intermediate response!) call HTTP-redirect fetch |
06:43 | <Domenic> | sorry s/HTTP-redirect fetch/navigate-redirect fetch/ |
06:43 | <Domenic> | Although I guess both expect the intermediate response |
06:43 | <annevk> | And with fetch(, { ... "manual" }) they are exposed of course and presumably reveal the "intermediate" timing. |
06:43 | <Domenic> | But the point I'm taking from you is that it'd be nicer for consumers if processResponse had the same semantics for both manual and non-manual redirects... I want to trace through the flow to see if that fails to be the case. |
06:44 | <Domenic> | I think this PR actually accomplishes that? |
06:44 | <Domenic> | Because only main fetch, in the no-Location-header case, calls processResponse |
06:45 | <annevk> | Wait, if that's the case how would you get a response when there is a Location header? |
06:45 | <Domenic> | Ah OK, but the problem is, where do we bail out and give HTML the intermediate response. |
06:46 | <Domenic> | OK so yes, I'm caught up now. I think a new callback would be good. |
06:46 | <Domenic> | ...maybe... |
06:46 | <annevk> | Wait, HTTP fetch returns a redirect-response to main fetch. |
06:47 | <annevk> | So I think "process response" is getting called for manual redirect responses, which is good, otherwise fetch() wouldn't even work. |
06:47 | <annevk> | Anyway, I think you and Yoav made a good point that the setup with navigate is somewhat broken already and that this would improve things. |
06:49 | <annevk> | So as long as we document that this setup can result in "process response" being called multiple times and essentially can resurrect a fetch that thought it was near the finish line, I think we're okay. |
06:50 | <Domenic> | OK, I'll try adding something about that |
06:50 | <Domenic> | I think you are right that "process response" is called for intermediate responses |
06:55 | <Domenic> | OK when writing guidance, there is a problem, which is you have no easy way of knowing which processResponse is the final one. |
06:56 | <annevk> | Domenic: wouldn't response's status tell you? |
06:56 | <Domenic> | Yeah, I guess there are ways |
06:56 | <annevk> | Domenic: might have to peak at the internal response for that, but this is only for "navigate" so... |
06:57 | <Domenic> | Right now HTML's strategy is to call navigate-redirect fetch and it's a no-op if we've reached the end. Then we look at the location URL. And only call navigate-redirect fetch if it's not null or failure. |
06:57 | <Domenic> | I guess I'll just recommend that strategy. |
07:03 | <Domenic> | Done https://whatpr.org/fetch/1469.html#fetch-elsewhere-fetch |
07:05 | <annevk> | TabAtkins: 101β took me a while, but I think you might be close to a year older than me. Enjoy whatever is left of your last hextury. π |
07:19 | <annevk> | Domenic: that looks good, but you prolly want to state that it also requires mode to be "navigate" |
07:20 | <annevk> | I'm gonna make some tea and then I'll do a proper review. I'm happy to help with nits, so I suspect we can land it in a bit |
07:21 | <Domenic> | Excellent, thanks! |
07:32 | <Noam Rosenthal> | Domenic, annevk thanks for moving this along, hope to return to capacity in a month-ish |
07:36 | <sideshowbarker> | annevk: https://stackoverflow.com/questions/74049310/distinguish-network-error-from-opaque-response-in-fetch-with-no-cors |
07:47 | <annevk> | Noam Rosenthal: enjoy your kiddo time, hope the nights are reasonable |
07:50 | <karlcow> | what does that mean? https://github.com/whatwg/compat/pull/215#issuecomment-1277180030 I didn't remove it anything related to this. |
07:50 | <karlcow> | did the check become stricter? |
07:56 | <annevk> | sideshowbarker: succesful nerd-snipe |
07:57 | <annevk> | It probably means that upstream has changed since you last updated the specification. |
07:59 | <annevk> | We run Bikeshed strictly so sometimes you'll find new problems like this. |
07:59 | <karlcow> | The references didn't seem to have ever been there. :) |
07:59 | <karlcow> | I guess we need to add a bit more |
08:00 | <karlcow> | thanks. :) I'll do that later. |
09:35 | <annevk> | Aside, you probably want to mark this as "Meta: " if you're just fiddling with references as per https://github.com/whatwg/meta/blob/main/COMMITTING.md |
12:00 | <annevk> | Anyone here familiar with W3C tooling? sideshowbarker maybe? When I commit to a W3C draft there's a subsequent commit done by a bot that links me and it's very annoying: https://github.com/w3c/webappsec-upgrade-insecure-requests/commit/9ea1e027ed1db4ad0b7d9c7e94ba7cfe9a0ac5f6 |
12:02 | <Ms2ger πππ> | I think it comes from here: https://github.com/w3c/spec-prod/blob/main/src/deploy-gh-pages.ts#L67 |
12:03 | <annevk> | I guess I'll try filing an issue against spec-prod |
12:05 | <annevk> | Better: https://github.com/w3c/spec-prod/pull/149 |
12:21 | <Ms2ger πππ> | Damn, that response time! |
12:41 | <karlcow> | yup |
12:53 | <karlcow> | oh probably https://github.com/tabatkins/bikeshed/pull/2364 |
14:48 | <johannhof> | Is there any guidance on writing error messages for exceptions? Looking at https://webidl.spec.whatwg.org/#dfn-exception-message those seem to be "user agent defined", but do we consider consistency valuable anyway here? |
15:09 | <Ms2ger πππ> | I don't think there's any guidance |
15:09 | <Ms2ger πππ> | Has anyone had the "commit suggestion" feature work for them on the html spec? |
15:10 | <freddy> | I think some features actually have tests in wpt on the exception details, but most don't. |
15:11 | <freddy> | The other thing that's worth looking out for is not leaking sensitive stuff (e.g., cross-origin URLs or redirect targets) in the exception's details |
15:14 | <annevk> | Ms2ger πππ: it doesn't work for source , too big (same with blame) |
15:15 | <annevk> | I would like message to not be implementation-defined, but it's a lot of work. (It does at times result in compatibility issues.) |
15:20 | <Ms2ger πππ> | Ms2ger πππ: it doesn't work for |
15:34 | <Ms2ger πππ> | Pushed a few more changes, I think https://github.com/whatwg/html/pull/5339 is in Domenic's court now |
16:20 | <TabAtkins> | I think there's still something slightly screwy with references even after that PR. I've screwed up my shoulder overnight so I dunno how much computer I'll be able to do today, but if I can this'll be my priority |
17:02 | <johannhof> | Thanks for the replies folks! I'll take that to mean that unless there's a strong reason not to, I'll try to match other browser's messages. |