09:47
<JakeA>
annevk: given https://html.spec.whatwg.org/multipage/comms.html#the-eventsource-interface sets a non-simple header, should it trigger a preflight for cross-origin urls? If not, which part of the fetch spec stops this?
09:48
<JakeA>
annevk: ignore me, sorry
09:48
<JakeA>
fffff
09:48
<JakeA>
misread
09:57
<zcorpan>
should we put something in the bug whiteboard for things like https://www.w3.org/Bugs/Public/show_bug.cgi?id=29329
10:25
<JakeA>
annevk: maybe of interest https://github.com/igrigorik/http-client-hints/issues/68
10:36
<MikeSmith>
zcorpan: in the whiteboard maybe we could put the URL for the PR? either that or the URL for the commit
10:38
<zcorpan>
MikeSmith: actually it's possible to search for /pull/ in comments, so i think it's not necessary to use the whiteboard
10:39
<zcorpan>
https://www.w3.org/Bugs/Public/buglist.cgi?component=HTML5%20spec&list_id=60910&longdesc=%2Fpull%2F&longdesc_type=casesubstring&product=HTML%20WG&query_format=advanced&resolution=---
10:41
<zcorpan>
or rather https://www.w3.org/Bugs/Public/buglist.cgi?component=HTML5%20spec&list_id=60911&longdesc=whatwg%2Fhtml%2Fpull%2F&longdesc_type=casesubstring&product=HTML%20WG&query_format=advanced&resolution=---
10:48
<zcorpan>
but some open bugs are invalid. maybe whiteboard is better anyway, whatwg-resolved
10:51
<MikeSmith>
oh clever
10:51
<MikeSmith>
but yeah maybe whatwg-resolved
11:03
<MikeSmith>
zcorpan: btw I just now notice the git log output for that commit shows you as the committer even though I merged it
11:03
<MikeSmith>
which I kind of like actually
11:04
<MikeSmith>
because the PR itself still records the fact that somebody other than you merged it
11:04
<zcorpan>
yeah. though the commit doesn't have any pointer to the PR, does it?
11:04
<MikeSmith>
but I don't know what I did differently that caused it to end up being logged that way
11:04
<jgraham>
Presumably the merge commit shows that you created/comitted it and the commit itself shows that zcorpan comitted it? Unless you aren't merging
11:05
<MikeSmith>
zcorpan: oh. no it doesn't
11:05
<zcorpan>
jgraham: merge --ff-only
11:05
<MikeSmith>
jgraham: what zcorpan just said
11:06
<MikeSmith>
I wonder if the cause of this is that I already have all branches for all the PRs checked out
11:06
<MikeSmith>
otherwise I don't know what would be different in my local environment
11:07
<MikeSmith>
because I think I use the same process to merge PRs
11:07
<zcorpan>
MikeSmith: i think it's usually like this if the merger doesn't make any changes
11:07
<MikeSmith>
ah OK
11:07
<zcorpan>
MikeSmith: but often we tweak the commit message or fix other things
11:07
<MikeSmith>
aha
12:57
<yoav>
annevk: thoughts on decoupling "supported tokens" redefinition from https://github.com/whatwg/dom/pull/123 ?
16:48
<MikeSmith>
wonder what the status of the Foreign Fetch proposal is at this point
16:49
<MikeSmith>
I know about https://wiki.whatwg.org/wiki/Foreign_Fetch but don't know if it's yet graduated out from there to anywhere else yet
17:32
<calvaris>
Domenic: do you have a moment?
17:36
<nikkibee>
https://fetch.spec.whatwg.org/#http-fetch the "set response's CSP list" link in substep 5 of step 3 leads to a 404
17:36
<nikkibee>
https://w3c.github.io/webappsec-csp/#set-response-csp-list this seems to be the correct url to link to
17:39
<MikeSmith>
nikkibee: yeah I recall finding at least one other broken reference in the Fetch spec a couple months ago, due the CSP anchors having changed
17:39
<gsnedders>
nikkibee: just open a bug/PR at https://github.com/whatwg/fetch
17:40
<nikkibee>
MikeSmith: that's annoying... although the new url actually matches the phrase, I guess
17:40
<nikkibee>
sure thing gsnedders
17:41
<gsnedders>
nikkibee: assuming the link is actually in overview.src.html
17:42
<nikkibee>
yep, I found it in there
17:43
<nikkibee>
if I make a PR for it should I open a bug for it first?
17:43
<gsnedders>
I don't think you need to?
17:43
<gsnedders>
esp. for something so simple and not any normative change
17:44
<nikkibee>
alright
17:49
<Domenic>
calvaris: at lunch but sure
17:50
<nikkibee>
https://github.com/whatwg/fetch/pull/173 PR made
17:51
<calvaris>
Domenic: https://github.com/whatwg/streams/blob/master/reference-implementation/web-platform-tests/readable-streams/cancel.js#L9
17:52
<calvaris>
if I understand correctly
17:52
<calvaris>
readableStreamToArray begins to read chunks
17:53
<calvaris>
after about 15ms + promise vending the reader is canceled
17:54
<calvaris>
that causes the current read to be vended as done
17:54
<Domenic>
Sounds right
17:56
<calvaris>
that should cause the internal read cascade is vended too
18:00
<calvaris>
meanwhile, the source cancel is called an the cancel promise is created with the timeout to be vended 1s after
18:00
<calvaris>
I don't know if it is normal or not
18:01
<calvaris>
but in WK the cancel timeout runs in some cases before the callback for readableStreamToArray
18:02
<calvaris>
which causes the cancellationFinished to be true
18:02
<calvaris>
I am not sure if that should/can happen or not
18:03
<Domenic>
calvaris: well the test does use timers which means it is prone to such flakes
18:03
<calvaris>
because if I am not wrong, the cascade of reads has to be resolved
18:03
<Domenic>
But it's surprising that your timers for 15 ms can fire before your timer for 1 ms
18:03
<calvaris>
and that can mess in some cases with the timers
18:04
<calvaris>
no, that does not happen
18:04
<calvaris>
well, it does, but of course because it is the 15ms timeout that causes the 1ms to be set to run
18:05
<Domenic>
Uh, why?
18:05
<Domenic>
Oh I see what you mean
18:05
<calvaris>
the source cancel timeout is set as a result of calling reader.cancel()
18:05
<calvaris>
so that's working as it should
18:06
<Domenic>
Well RandomPushSource should only take 2 ms to give you a chunk
18:08
<calvaris>
that's not the issue, I guess, the issue seems to be the asynchronous stuff happening with promise vending
18:08
<calvaris>
because the reads are vended before and there's a cascade of several reads that have to be vended to be returned by readableStreamToArray
18:10
<calvaris>
and then we have the call to the source, which creates the promise that sets timeout to reset the boolean to true and vends the cancel promise
18:10
<Domenic>
Stepping back, what is actually the problem with the ordering you see. It doesn't cause failure does it?
18:10
<calvaris>
it does cause failure
18:10
<Domenic>
Oh it does because cancelationFinished
18:10
<calvaris>
yep
18:10
<Domenic>
I see
18:11
<Domenic>
OK this is actually something important being tested...
18:11
<Domenic>
Can you file an issue so I am able to write this up better when I get back to my computer?
18:11
<calvaris>
sure
18:12
<calvaris>
and thanks for answering during your lunch
19:11
<frewsxcv>
anyone want to review https://github.com/w3c/csswg-test/pull/969 ?
19:12
<Ms2ger>
jgraham, ^
20:48
<annevk>
rbyers: could you ping me early next week if I haven't started reviewing your work?
20:48
<rbyers>
annevk: Sure, would love to :-)
20:48
<annevk>
rbyers: there's been some vacation and Mozilla week is now so...
20:49
<rbyers>
Figured I had no business bothering you after I disappeared for a month ;-)
20:49
<annevk>
heh, don't worry
20:50
<rbyers>
Thanks though! We're preceding with implementation under the assumption that it's mostly minor details and editorial left to agree on... Lots of tough implementation work to do to get the real perf benefit from passive listeners...
21:05
<nikkibee>
annevk: I can't figure out what's wrong with my link in https://github.com/whatwg/fetch/pull/173
21:05
<nikkibee>
the url works for me, and it matches the section named in the text
21:09
<annevk>
nikkibee: there's another broken link
21:09
<annevk>
nikkibee: there's two identical wrong links, you only replaced one, afaict
21:09
<nikkibee>
ohh, I see!
21:10
<nikkibee>
I had not thought of that
21:10
<nox>
nikkibee: Hello here, good luck with Fetch. :)
21:10
<nikkibee>
thanks nox!
21:11
<nikkibee>
annevk: fixed and pushed. would you like me to combine my two commits into one before merging it?
21:12
<annevk>
nikkibee: if you can, that'd be lovely
21:12
<nikkibee>
sure thing
21:21
<nikkibee>
I keep forgetting how to squash my commits... I'm going to have ot just write it down on paper after I dig up my history on it yet again
21:21
<annevk>
nikkibee: so yeah, rebase -i HEAD~{number of commits that need to go together}
21:22
<annevk>
nikkibee: I have to search for it every time
21:22
<annevk>
so annoying
21:22
<nikkibee>
annevk: heh, at least I'm not the only one...
21:22
<gsnedders>
the other thing that's useful is: git rebase -i `git merge-base origin/master HEAD`
21:22
<nikkibee>
I just remember I can never figure out all the steps myself
21:22
<gsnedders>
quite possibly with --autosquash
21:23
<nikkibee>
I'll tr ythat
21:23
<nikkibee>
gsnedders: are those supposed to be two lines? I don't understand how to run that
21:24
<gsnedders>
(--autosquash moves the initial state around if you've used `git commit --fixup= or --squash=` before)
21:24
<gsnedders>
nikkibee: one command. git rebase -i --autosquash `git merge-base origin/master HEAD`
21:25
<nikkibee>
git just tells me my usage options, it doesn't accept that line
21:25
<nikkibee>
I'm using it exactly as you typed it
21:25
<gsnedders>
with the backticks?
21:26
<nikkibee>
yeah
21:26
<gsnedders>
because that /should/ work. what part is it objecting to?
21:26
<gsnedders>
the first line before the help should be the error, IIRC
21:26
<nikkibee>
I get no error
21:27
<nikkibee>
it just goes straight to "usage: git rebase [-i] [options] [--exec <cmd>] [--onto <newbase>] [<upstream>]" etc
21:27
<nikkibee>
oh wait, should I be using that --exec flag?
21:28
<gsnedders>
no
21:28
<nikkibee>
okay
21:28
<gsnedders>
no error? that's really weird
21:28
<gsnedders>
what version of git, actually?
21:28
<nikkibee>
git version 1.9.5.msysgit.0
21:29
<nikkibee>
I'm on windows, if that makes any difference
21:29
<caitp>
that is a pretty oldschool git
21:29
<gsnedders>
nikkibee: oh, that won't support --autosquash
21:29
<gsnedders>
sorry, I've not touched git < 2 in a while :)
21:30
<nikkibee>
gsnedders: I got the same result with the first command
21:30
<nikkibee>
git is beyond version 2?
21:30
<gsnedders>
2.6.something now
21:30
<nikkibee>
oh geeze
21:30
<nikkibee>
I didn't know I was so out of date what the heck
21:30
<gsnedders>
I dunno if the Windows port stays up to date nowadays.
21:30
<gsnedders>
I haven't paid attention to that in ages.
21:30
<nikkibee>
it does, it's 2.6 something as well
21:31
<gsnedders>
--fixup and --squash on commit are great features with --autosquash
21:32
<gsnedders>
idk why it's failing without --autosquash, really, but if you're so out of date update first!
21:32
<nikkibee>
ya I'm updating
21:32
<nikkibee>
I don't know how I got such an out of date version... I would have first installed it like 10 months ago on this laptop?
21:34
<nikkibee>
damn, it's still doing this annoying non-error
21:35
<caitp>
what is the annoying non-error?
21:36
<nikkibee>
it just tells me usage options for git rebase
21:36
<nikkibee>
it doesnt' tell me what is wrong
21:36
<caitp>
it doesn't say "error: unknown switch" or something before that?
21:37
<nikkibee>
no, nothing of the sort
21:38
<nikkibee>
I found the old logs from before where I first learned how to do git rebase, I'll just try following that
21:38
<nikkibee>
and then write it down for prosperity, finally
21:39
<nikkibee>
I thoguht I had before but I can't find it
21:41
<nikkibee>
there we go... one commit now on the PR @ annevk!
21:41
<annevk>
oh wow, sorry you went through all that trouble
21:41
<nikkibee>
thanks for the suggestion thoguh gsnedders, I'm used to git on windows being uniquely obtuse
21:42
<nikkibee>
it's okay annevk, figuring it out the first time was much worse!
21:45
<annevk>
nikkibee: congrats on your first commit!
21:45
<nikkibee>
thanks annevk :)
21:45
<nikkibee>
I've contributed to whatwg before though. having contributed to two different standards is pretty nifty though
21:47
<annevk>
next: write a standard :😃
21:47
<nikkibee>
haha
21:47
<nikkibee>
I would, but there's just too many standards
21:48
<nox>
nikkibee: s/on windows/
21:48
<nikkibee>
oh, I should write a standard for writing standards. that'll solve everything! ;)
21:48
<nox>
Git is obtuse, bad, and we all suffer from Stockholm's syndrome.
21:48
<nikkibee>
nox: that seems to be my impression
21:48
<nikkibee>
only on windows tho does it force you to know about CRLF settings
21:49
<nikkibee>
there's a special git error that only comes up on windows I ran into once, git kept saying some files I never edited were changed and wouldn't let me push or pull from this persons repo, even if I downloaded it again. cause it was changing the CRLFs in the files, which shows up as nothing
21:53
<nikkibee>
CRLF is messed up
22:22
<jgraham>
Hmm, git < 2 supports autosquash, windows doesn't support backticks (possibly)
22:28
<gsnedders>
I was about to say what jgraham just said.
22:28
<gsnedders>
Just realising that.
22:30
<Ms2ger>
What's --squash?
22:32
<gsnedders>
Ms2ger: The difference between --squash and --fixup is --squash keeps the commit message, --fixup drops it
22:33
<Ms2ger>
So you end up with fo\n\nbar or something?
22:34
<jgraham>
It's just the same as the options in the rebase UI
22:34
<gsnedders>
Ms2ger: yeah
22:34
<gsnedders>
what jgraham said, too
22:34
<gsnedders>
the use of the flags on git commit is just for the sake of autosquash