| 00:26 | <wanderview> | Domenic: in streams section 3.9.5 (ReadableStreamDefaultControllerEnqueue), does step 5.d.ii mean to rethrow the exception? I'm not really familiar with the "abrupt cancellation" terminology |
| 00:26 | <wanderview> | Domenic: woops... mean step 5.b.ii.2 |
| 00:26 | <wanderview> | or I guess its the same usage there |
| 00:37 | <Domenic> | wanderview: yep, that's the idea. |
| 00:38 | <wanderview> | Domenic: I thought I was finally starting to understand spec language... and then I have to go learn ES spec language :-) |
| 00:38 | <Domenic> | wanderview: it builds character ;) |
| 00:38 | <wanderview> | it builds something |
| 04:52 | <howdoi> | what was the exact reason why Object.observe brought down? |
| 05:11 | <MikeSmith> | howdoi: https://esdiscuss.org/topic/an-update-on-object-observe |
| 05:17 | <howdoi> | Thanks MikeSmith |
| 07:28 | <Ms2ger> | hallvors, ping |
| 07:29 | <hallvors> | Ms2ger: pong |
| 07:29 | <Ms2ger> | hallvors, trying to figure out where the spec backs http://w3c-test.org/XMLHttpRequest/send-content-type-charset.htm |
| 07:29 | <Ms2ger> | Especially the "charset given but wrong, fix it" ones |
| 07:31 | <hallvors> | Let me investigate a bit - we may have to ping annevk too, I think several of those assertations were written by him originally |
| 07:32 | <annevk> | Ms2ger: anything not backed by step 4 of https://xhr.spec.whatwg.org/#the-send()-method is likely wrong |
| 07:33 | <Ms2ger> | Oh wait |
| 07:33 | <annevk> | Ms2ger: it seems to be testing that from skimming it and those requirements might well have been tweaked a little bit since I wrote that test (or part of it) |
| 07:33 | <Ms2ger> | Ah, I seem to have missed the last paragraph |
| 07:34 | <annevk> | ok |
| 07:34 | <hallvors> | I was about to point to step 4, last para too :) |
| 07:35 | <Ms2ger> | Though I'm not sure that requires the exact string values in the test |
| 07:35 | hallvors | notes that even the test's meta data is correct |
| 07:36 | <hallvors> | for once :) (lots of meta data is outdated and I have ambitious plans for fixing that) |
| 07:37 | <Ms2ger> | Someone want to reply to https://github.com/w3c/web-platform-tests/issues/3121? |
| 07:39 | <MikeSmith> | zcorpan: about experimenting with https://github.com/whatwg/html/issues/1351 “Remove parse error for dashes in comments”, do we want to experiment with also dropping the warning “The document is not mappable to XML 1.0 due to two consecutive hyphens in a comment.”, or do you want to continue to emit that? |
| 07:40 | <hallvors> | annevk - I mostly agree with the 3121 issue, but I think you defended the test when I brought it up earlier ("be strict in what you send" etc). Leaving to you to reply ;) |
| 07:41 | <zcorpan> | MikeSmith: i think we should keep that, at least for now. if the people using the validator don't care about those warnings then all of them should be turned off by default, not just for -- in comments |
| 07:41 | <MikeSmith> | ok |
| 07:41 | <zcorpan> | imho |
| 07:41 | <MikeSmith> | yeah |
| 07:42 | <MikeSmith> | zcorpan: OK so FYI take a look at the adjustDoubleHyphenAndAppendToStrBufAndErr function at https://github.com/validator/htmlparser/blob/master/src/nu/validator/htmlparser/impl/Tokenizer.java#L922 |
| 07:43 | <MikeSmith> | and https://github.com/validator/htmlparser/blob/master/src/nu/validator/htmlparser/impl/Tokenizer.java#L476 |
| 07:43 | <MikeSmith> | I guess by default it does ALTER_INFOSET |
| 07:44 | <MikeSmith> | ah wait though, if that were true it wouldn’t be emitting the warning |
| 07:44 | <MikeSmith> | will need to look at the checker code further to see what it is setting |
| 07:45 | <zcorpan> | maybe the validator doesn't use the parser's default |
| 07:45 | <MikeSmith> | yeah I think it must not |
| 07:45 | <MikeSmith> | anyway, the simplest change would of course be just to drop the errConsecutiveHyphens(); call at line 924 |
| 07:45 | <annevk> | Ms2ger: hallvors: I left a reply |
| 07:46 | <MikeSmith> | zcorpan: but in looking at that code, I could also just move the errConsecutiveHyphens() call into the ALLOW and FATAL cases |
| 07:47 | <MikeSmith> | so that for ALTER_INFOSET case it would just silently alter the infoset, with no error and no warning |
| 07:48 | <zcorpan> | MikeSmith: don't we still want to use ALLOW in the checker? |
| 07:48 | <MikeSmith> | I guess in the context of the checker it doesn’t really matter much since nothing actually consumes the parse tree it creates |
| 07:48 | <zcorpan> | to get the warning if nothing else |
| 07:48 | <MikeSmith> | OK |
| 07:49 | <MikeSmith> | so that is what I will do for not |
| 07:49 | <MikeSmith> | *for now |
| 07:49 | <MikeSmith> | and push it to https://checker.html5.org/ |
| 07:50 | <zcorpan> | MikeSmith: what about <!-- <!-- --> |
| 07:51 | <annevk> | https://github.com/w3c/webcomponents/issues/496#issuecomment-223529711 o_O |
| 07:56 | <zcorpan> | MikeSmith: https://github.com/validator/htmlparser/blob/master/src/nu/validator/htmlparser/impl/Tokenizer.java#L2602 was also moved to be an error when seeing ">" in COMMENT_END_BANG instead |
| 07:58 | <MikeSmith> | zcorpan: what about it? we want to try to dropping that error too? |
| 07:59 | <zcorpan> | MikeSmith: it's a new error, that won't be reported otherwise |
| 08:00 | <MikeSmith> | oh |
| 08:00 | <MikeSmith> | we we want to *add* new reporting for it? |
| 08:00 | MikeSmith | looks back that the issue discussion |
| 08:00 | <zcorpan> | MikeSmith: https://github.com/whatwg/html/pull/1356/commits/b4d672b4976740cea236f197cc340a066cf0ac6e |
| 08:04 | <MikeSmith> | zcorpan: https://github.com/validator/htmlparser/blob/master/src/nu/validator/htmlparser/impl/Tokenizer.java#L2602 is for --! right? |
| 08:05 | <MikeSmith> | how is that relevant? |
| 08:06 | <zcorpan> | right. i suppose it's a separate thing but i changed it in the PR, because i didn't see any reason to disallow <!-- --! --> |
| 08:08 | <MikeSmith> | ok |
| 08:08 | <zcorpan> | sorry this was not a one-line change :-) |
| 08:15 | <MikeSmith> | heh |
| 08:15 | <MikeSmith> | OK will need to set aside more time to write it up |
| 08:15 | <zcorpan> | 👍 |
| 08:26 | <Manishearth> | annevk: https://fetch.spec.whatwg.org/#cors-preflight-fetch-0 |
| 08:26 | <Manishearth> | annevk: from what it says there, if you have a header `content-type: x-pony`, which is not in accesscontrolallowheaders, it should error, yes? |
| 08:27 | <Manishearth> | because http://web-platform.test:8000/XMLHttpRequest/send-redirect-to-cors.htm seems to think otherwise? |
| 08:27 | <annevk> | Manishearth: yeah, that's not a CORS-safelisted request-header |
| 08:28 | <Manishearth> | so is the test wrong? O.o |
| 08:28 | <Manishearth> | it somehow passes in firefox |
| 08:28 | <Manishearth> | hold on |
| 08:30 | <Manishearth> | annevk: ok, not sure what's going on, this test should fail |
| 08:30 | <Manishearth> | (it fails in servo, but not firefox) |
| 08:31 | <annevk> | Manishearth: looking at corsenabled.py I'm not sure why it should fail |
| 08:32 | <Manishearth> | annevk: as in? |
| 08:32 | <Manishearth> | annevk: we send a content-type: x-pony header with it |
| 08:32 | <Manishearth> | so the preflight fetch should return a network error, since that's not an allowed header |
| 08:32 | <annevk> | Oh yes, and it seems Firefox doesn't even issue a preflight here |
| 08:33 | <annevk> | Unless the network console cannot be trusted |
| 08:33 | <Manishearth> | annevk: I just assumed that the preflight isn't put in the network console |
| 08:35 | <annevk> | I hope that's not true |
| 08:35 | <Manishearth> | annevk: oh, from the wptserve log -- it doesn't |
| 08:35 | <Manishearth> | annevk: it should be issuing a preflight, right? |
| 08:35 | <annevk> | Yeah, I think so, otherwise you could use a redirect to circumvent preflights... |
| 08:35 | <annevk> | Which seems to be what is happening here |
| 08:36 | <Manishearth> | huh |
| 08:36 | <Manishearth> | chrome fails these tests |
| 08:36 | <Manishearth> | but not the way servo fails |
| 08:36 | <annevk> | Yeah, also in a weird way |
| 08:36 | annevk | curses redirects |
| 08:36 | <Manishearth> | chrome, too, doesn't do preflights |
| 08:37 | <Manishearth> | brb filing bug on chrome to make tons of bounty monies |
| 08:37 | <Manishearth> | chrome doesn't preflight, but it *does* scrub the headers |
| 08:37 | <annevk> | Manishearth: can you file one against Firefox too and against wpt? |
| 08:38 | <Manishearth> | right |
| 08:38 | <annevk> | Not the best way to start the day |
| 08:38 | <Manishearth> | heh :) |
| 08:38 | <Manishearth> | well, for once the failure isn't servo's fault :) |
| 08:38 | <Manishearth> | annevk: chrome runs wpt too, right? |
| 08:39 | <annevk> | I'm not sure at what stage they are |
| 08:39 | <Manishearth> | annevk: given that no browser does this properly, I assume this isn't a security bug (for firefox?) |
| 08:39 | <annevk> | Manishearth: it kinda is, but we just discussed it in public |
| 08:40 | <annevk> | Manishearth: copy Jonas Sicking |
| 08:40 | <Manishearth> | yeah |
| 08:44 | <Manishearth> | annevk: https://github.com/w3c/web-platform-tests/issues/3123 |
| 08:45 | <Manishearth> | should we mark it an easy bug? |
| 08:47 | <annevk> | Manishearth: probably not, since we want to keep some variant of that test around |
| 08:47 | <annevk> | Manishearth: we just need to change the pass conditions |
| 08:47 | <annevk> | Manishearth: and I guess we want a new test for what the old test actually wanted to test |
| 08:48 | <Manishearth> | annevk: right, the current test should check for a network error |
| 08:52 | <Manishearth> | annevk: how do you recommend I write a testcase for this? |
| 08:56 | <annevk> | Manishearth: the existing testcase can be changed to invoke assert_unreached() from xhr.onload and test.done() from xhr.onerror |
| 08:56 | <Manishearth> | annevk: but that needs wpt |
| 08:56 | <Manishearth> | I want to write one that doesn't need wpt |
| 08:56 | <Manishearth> | trying to write a netcat test case rn |
| 08:57 | <annevk> | Manishearth: what are you looking to test? |
| 08:57 | <Manishearth> | annevk: that the preflight doesn't happen |
| 08:57 | <Manishearth> | for the gecko/chrome bug |
| 08:58 | <annevk> | Manishearth: you could test that if a preflight did happen, the server would reply something bogus |
| 09:08 | <Manishearth> | annevk: ok, now I'm not sure what's happening |
| 09:08 | <Manishearth> | I am getting an OPTIONS request with http://manishearth.anapnea.net/tmp/test.html |
| 09:08 | <Manishearth> | I don't get one if there are no headers, but that's ok |
| 09:09 | <Manishearth> | on firefox, that is |
| 09:09 | <annevk> | Manishearth: what if you set Content-Type instead? |
| 09:11 | <Manishearth> | annevk: no OPTIONS, only GET |
| 09:12 | <annevk> | Manishearth: there you go |
| 09:12 | <annevk> | Manishearth: and without redirect? |
| 09:12 | <annevk> | Manishearth: I guess maybe the check post-redirect is not the same check as normal, which would be pretty bad architecture |
| 09:13 | <Manishearth> | annevk: both firefox and chrome skip OPTIONS when there are no strange headers, even on a direct XHR |
| 09:13 | <Manishearth> | and they replace POST with GET |
| 09:14 | <Manishearth> | in both cases |
| 09:14 | <Manishearth> | the only time I get OPTIONS is when I add a strange header |
| 09:15 | <Manishearth> | this happens even without redirects |
| 09:15 | <Manishearth> | cookies are scrubbed, too |
| 09:15 | <annevk> | So basically Firefox does not restrict Content-Type: unknown/type? |
| 09:15 | <Manishearth> | oh, not tried that |
| 09:15 | <annevk> | Sure, no cookies is normal |
| 09:15 | <annevk> | Replacing POST with GET based on a redirect is normal |
| 09:15 | <annevk> | That's all per spec |
| 09:16 | <Manishearth> | annevk: yeah, it does not restrict |
| 09:16 | <annevk> | o_O |
| 09:16 | <Manishearth> | chrome just scrubs the content-type header if it's strange |
| 09:16 | <annevk> | Pffff |
| 09:17 | <Manishearth> | no, chrome unconditionally scrubs that header |
| 09:17 | <Manishearth> | annevk: wait I goofed up |
| 09:17 | <Manishearth> | hold on |
| 09:17 | <annevk> | ooh |
| 09:18 | <Manishearth> | on direct POST, with content type text/plain |
| 09:18 | <Manishearth> | firefox keeps it a post |
| 09:18 | <Manishearth> | and keeps the content |
| 09:18 | <Manishearth> | if the content-type is strange, it gives an OPTIONS |
| 09:19 | <annevk> | Okay, so only with a redirect? |
| 09:19 | <Manishearth> | chrome has the same behavior for direct |
| 09:20 | <Manishearth> | on redirects |
| 09:20 | <Manishearth> | all POSTs become GETs |
| 09:20 | <Manishearth> | good content-types are let through |
| 09:20 | <Manishearth> | firefox lets through bad content-types |
| 09:20 | <Manishearth> | chrome scrubs them |
| 09:21 | <annevk> | So both those behaviors are wrong |
| 09:21 | <Manishearth> | but not dangerous |
| 09:21 | <annevk> | POST -> GET is fine, for 301/302 (not the others) |
| 09:22 | <Manishearth> | annevk: why is not sending a preflight ok? |
| 09:22 | <annevk> | Manishearth: that part is not okay |
| 09:23 | <Manishearth> | annevk: even when there is a text/plain content type? |
| 09:23 | <annevk> | Manishearth: scrubbing is not okay either |
| 09:23 | <annevk> | Manishearth: text/plain is safelisted |
| 09:23 | <Manishearth> | annevk: yeah, but spec-wise that check happens *after* the preflight, no? |
| 09:23 | <annevk> | Manishearth: no |
| 09:24 | <hallvors> | I think the short-term fix for the test suite bug is to set headers allowed to * |
| 09:24 | <annevk> | Manishearth: we check for safelisted request-headers and only if they're outside that range we preflight |
| 09:24 | <hallvors> | But given the details here we clearly need better tests |
| 09:24 | <Manishearth> | huh |
| 09:24 | <hallvors> | so we can catch the implementations that are currently not quite doing the right thing |
| 09:24 | <Manishearth> | okay, so servo has a bug here too |
| 09:24 | <annevk> | hallvors: that's not a good fix |
| 09:24 | <Manishearth> | you get a bug. you get a bug. everybodygetsabug! |
| 09:24 | <annevk> | hallvors: first of all, * is a new feature for those headers so won't work |
| 09:25 | <hallvors> | ah..so we're having this discussion because the spec is changing? Got it.. |
| 09:25 | <annevk> | hallvors: we could add "content-type" to the list, but apparently the preflight is not even happening, so we also need some tests that set other headers |
| 09:25 | <annevk> | hallvors: noooo |
| 09:26 | <annevk> | hallvors: we're having this discussion because implementations have bugs with the spec as written before wildcarding became a thing for header names |
| 09:26 | <Manishearth> | annevk: btw, where in the spec does it mention POST -> GET for redirects? |
| 09:26 | <hallvors> | well, we need better tests - so we can use Manishearth's bug for that |
| 09:26 | <Manishearth> | wait no nv |
| 09:26 | <Manishearth> | nvm |
| 09:27 | <annevk> | Manishearth: in the HTTP-redirect section |
| 09:27 | <Manishearth> | yeah, found it |
| 09:27 | <annevk> | Manishearth: fairly recent change (HTTP calls it out a bit, but not normative enough) |
| 09:27 | <hallvors> | BTW to all in #whatwg - there's a request for more tests here, should be trivial to add: https://github.com/w3c/web-platform-tests/issues/3124 - would be great if someone could jump in and add stuff :) |
| 09:28 | <Manishearth> | annevk: yeah, there's even servo code handling that, wonder why it didn't get hit |
| 09:28 | <Manishearth> | wait, no, it *did* get hit |
| 09:28 | <Manishearth> | hm |
| 09:38 | <Manishearth> | annevk: why are we nitpicky baout content-type, btw? |
| 09:38 | <Manishearth> | *about |
| 09:38 | <Manishearth> | there is no content anyway, that gets scrubbed |
| 09:39 | <Manishearth> | also, why only 301/302/303 for making the method GET? |
| 09:41 | <annevk> | Manishearth: same-origin policy violations for Content-Type was restricted to <form> historically |
| 09:41 | <Manishearth> | ah |
| 09:42 | <Manishearth> | annevk: but form doesn't use fetch? |
| 09:42 | <annevk> | Manishearth: only 301/302 change POST to GET for historical reasons, mostly because browsers maybe mistakenly did that and sites relied on it |
| 09:42 | <annevk> | Manishearth: 303 changes to GET always because that's just what it does |
| 09:42 | <Manishearth> | annevk: what happens for the other redirect methods? |
| 09:42 | <Manishearth> | or are those the only 3 ? |
| 09:42 | <annevk> | Manishearth: <form> uses navigate which uses fetch, but it doesn't use "cors", it uses "navigate" |
| 09:42 | <Manishearth> | oh, navigate uses fetch now? |
| 09:42 | <annevk> | Manishearth: 307/308 preserve the method |
| 09:42 | <annevk> | Manishearth: more or less |
| 09:43 | <Manishearth> | annevk: what about script/link/etc? |
| 09:43 | <annevk> | Manishearth: there's a lot of work to be done still, hopefully over the summer |
| 09:43 | <annevk> | Manishearth: yeah those all use Fetch |
| 09:43 | <Manishearth> | oh ok |
| 09:43 | <Manishearth> | oh, really?nice |
| 09:43 | <annevk> | Yeah, that happened last year I think |
| 09:43 | <Manishearth> | I saw some changes but wasn't sure if it was everywhere yet |
| 09:45 | <hallvors> | annevk: another XHR question in https://bugzilla.mozilla.org/show_bug.cgi?id=918764 - about letters (not) allowed in script-set headers |
| 09:46 | <annevk> | hallvors: there's a couple of spec issues on that |
| 09:46 | <hallvors> | I'm just skimming bugmail - is RFC 7230 too strict for the web, or is the test misinterpreting it? If all browsers fail the test is probably wrong.. |
| 09:46 | <annevk> | hallvors: might be too strict |
| 09:46 | <hallvors> | a few links in the bug report would be great :) |
| 09:47 | <Manishearth> | annevk: https://bugzilla.mozilla.org/show_bug.cgi?id=1278493 |
| 09:51 | <annevk> | hallvors: done |
| 09:51 | <annevk> | Manishearth: ta |
| 09:52 | <Manishearth> | Domenic: filed https://bugs.chromium.org/p/chromium/issues/detail?id=617902 |
| 09:54 | <hallvors> | annevk: thanks :) |
| 10:21 | <Manishearth> | annevk: more possibly buggy spec tests? |
| 10:21 | <Manishearth> | annevk: https://fetch.spec.whatwg.org/#concept-http-fetch |
| 10:21 | <Manishearth> | the 401 line |
| 10:21 | <Manishearth> | response is returned if request's credentials mode is not "include". |
| 10:21 | <Manishearth> | however |
| 10:22 | <Manishearth> | https://xhr.spec.whatwg.org/#the-send()-method |
| 10:22 | <Manishearth> | > If the withCredentials attribute value is true, "include", and "same-origin" otherwise. |
| 10:22 | <Manishearth> | so by default the credentials mode is same origin |
| 10:24 | <Manishearth> | however, https://github.com/w3c/web-platform-tests/blob/master/XMLHttpRequest/send-authentication-competing-names-passwords.htm doesn't set withcredentials |
| 10:25 | <Manishearth> | annevk: perhaps the spec should say "the cors flag is set AND credentials mode is not include" |
| 10:30 | <Manishearth> | annevk: https://github.com/whatwg/fetch/issues/319 |
| 10:40 | <howdoi> | try-catch with async-await is a pain in the.... |
| 10:40 | <howdoi> | Object.values but not give null values? |
| 10:56 | <annevk> | Manishearth: why? |
| 10:56 | <annevk> | Manishearth: it says one of |
| 11:20 | <annevk> | Ah, will follow up in the issue |
| 11:27 | <Manishearth> | annevk: so the spec needs fixing, right? I wasn't sure from your response |
| 11:31 | <annevk> | Manishearth: I think so |
| 13:34 | <annevk> | Domenic: so what does fetch(..., { token }) mean per ES6? |
| 13:58 | <Domenic> | annevk: fetch(..., { token: token }) |
| 13:59 | <annevk> | Domenic: interesting |
| 14:02 | <annevk> | Domenic: does it take after the variable name? |
| 14:03 | <Domenic> | annevk: if I understand what you're asking, yes? |
| 14:03 | <Domenic> | It's just a shortcut. { x } is always shortcut for { x: x } |
| 14:03 | <annevk> | ta |
| 14:04 | <annevk> | I think at some point I learned about that and then never used it enough to remember |
| 16:16 | <nox> | annevk: How stable is the CE spec now? |
| 16:16 | <nox> | Is it ready to be implemented in Q3? |
| 16:35 | <annevk> | nox: yeah |
| 16:42 | <annevk> | Domenic: I guess you run tip-of-tree bikeshed? |
| 16:43 | annevk | should probably update |
| 16:43 | <Domenic> | annevk: yeah, I git pull and bikeshed update before every commit... |
| 16:43 | <annevk> | I see |
| 17:26 | <annevk> | Domenic: https://twitter.com/bergi_bergos/status/740193424209522688 |
| 22:14 | <nox> | Is it just me or DOM uses CEReactions but doesn't include a reference to its definition? |
| 22:23 | <Domenic> | nox: yeah, https://github.com/tabatkins/bikeshed/issues/677 |
| 22:24 | <nox> | Domenic: Thanks for the link. |
| 22:35 | <TabAtkins> | That's an easy fix, I should get on that one. |
| 22:36 | <TabAtkins> | However, I just added support for getting the 100% accurate line number from a line! |
| 22:36 | <TabAtkins> | Just need to annotate every single die()/warn() call to pass the right info. |
| 22:37 | <TabAtkins> | s/from a line/for an error/ |