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 source, too big (same with blame)
too bad
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.