| 01:59 | <Domenic> | domfarolino: that sounds great to me. One for each class, I think |
| 02:00 | <Domenic> | jyasskin: if the fields on the instances never change, then it's OK, although perhaps it's a bit trickier for the reader to know that ahead of time. (Although, indirecting through more abstraction might also be trickier for the reader.) |
| 02:01 | <Domenic> | jyasskin: I think Fetch does this pretty well with its `Response`-has-an-associated-response-struct separation? |
| 02:02 | <domfarolino> | Domenic: Perfect. Also...I was considering submitting a PR to wpt removing https://github.com/w3c/web-platform-tests/blob/master/fetch/api/request/request-idl.html#L40 and some other lines that use the `type` parameter since https://github.com/whatwg/fetch/pull/582 has been merged, does this sound OK, as correct implementations incorrectly fail a couple tests now? |
| 02:03 | <domfarolino> | Or would we want to take it a step further and assert that `type` does not exist as an attribute or something (less confident in this option) |
| 02:04 | <Domenic> | Oh, yeah, so updating the IDL tests is always good. foolip has been looking into centralizing all of those into https://github.com/w3c/web-platform-tests/tree/master/interfaces . |
| 02:04 | <Domenic> | Adding a -historical.html test that asserts that something is gone is a nice bonus |
| 02:05 | <Domenic> | Example https://github.com/w3c/web-platform-tests/blob/master/html/semantics/tabular-data/historical.html (but there are lots of different styles if you Ctrl+F for historical.html) |
| 02:10 | <domfarolino> | Domenic: Thanks! |
| 04:37 | <jyasskin> | Domenic: https://fetch.spec.whatwg.org/#concept-response-response does kind of exemplify the problem: since fields of the response struct change, it's not really any safer to use in parallel than the interface that it's associated with. |
| 04:50 | <annevk> | jyasskin: they can change but not always |
| 04:50 | <annevk> | jyasskin: we discussed this here recently |
| 04:51 | <annevk> | jyasskin: my suggestion was that we ensure things are safe via review and try to uplift as we learn |
| 04:52 | <annevk> | jyasskin: our type system is still incomplete too; suspect when that is better and we have more common operations defined we can suitably restrict in parallel |
| 04:56 | <jyasskin> | annevk: Yeah, reviewing for actual races seems reasonable. Are we also avoiding use of interfaces from parallel sections, or just avoiding races on their fields? |
| 04:56 | <jyasskin> | (In particular, readonly fields and internal slots could be safe.) |
| 04:57 | <annevk> | jyasskin: only internal slots could be safe |
| 04:57 | <annevk> | jyasskin: it seems okayish to do that, maybe with a note explaining why you need not be alarmed |
| 04:57 | <jyasskin> | ... because readonly fields' getters use something from the current global? |
| 04:58 | <annevk> | jyasskin: yeah, and because we don’t know if it still holds the same getter |
| 04:58 | <jyasskin> | 'k, thanks. |
| 07:19 | <domfarolino> | annevk: Is it possible to observe anything besides "about:client" or "" when looking at Request.referrer? My understanding is that the fetch algorithm may set the Request's referrer to a URL, but this will be on a copy of the passed in Request object...so can you ever observe this URL in application code? |
| 07:41 | <annevk> | domfarolino: in a service worker, but you can also set it to a same-origin URL |
| 07:48 | <domfarolino> | annevk: ah ok how do |
| 07:48 | <domfarolino> | annevk: you set it? |
| 07:49 | <annevk> | annevk: fetch(url, { referrer: "/hi" }) |
| 12:30 | <tobie> | annevk: think you can take a look at: https://github.com/whatwg/infra/pull/155#issuecomment-332964862 at some point? |
| 12:33 | <annevk> | tobie: oh sorry, I thought that landed already |
| 12:33 | <tobie> | annevk: np |
| 12:36 | <annevk> | tobie: squashed and merged |
| 12:36 | <tobie> | annevk: ta |
| 12:36 | <annevk> | tobie: feel free to ping sooner next time |
| 12:37 | <annevk> | tobie: if I haven't replied within a day or two it's highly likely I missed something |
| 12:37 | <tobie> | annevk: the pr that needs it is far from being ready |
| 12:37 | <tobie> | annevk: so there was no reason to stress anyone out. :) |
| 13:40 | <rwaldron> | annevk thanks for the confirmation |
| 13:43 | <annevk> | rwaldron: I hope you can find some joy in working on this, since there's a lot of sad things in that algorithm |
| 13:45 | <rwaldron> | I cannot lie, it's been a slog getting to where I am now. I have a WIP branch that includes informative prose that describes "what this test file is actually doing, and what spec parts are relevant to that end". |
| 13:46 | <annevk> | Coupled with reverse engineering browsers it can indeed be rather painful |
| 13:46 | <rwaldron> | Each file has a special multiline comment area that contains meta data (I'm using yaml, because it's easy to type) |
| 13:46 | <rwaldron> | Yes, I've been carrying around two computers for the last month |
| 13:46 | <rwaldron> | A MBP and Surface Book |
| 13:47 | <annevk> | What I personally enjoy about is that once I've solved some gnarly task like that hopefully nobody else will have to |
| 13:47 | <rwaldron> | That's definitely the silver lining |
| 14:48 | <tobie> | mkwst: Does `new A().foo()` throw a SecurityError in this context: [SecureContext, Constructor] interface A : B {}; interface B { void foo(); }; The spec says no. Can you confirm? |
| 14:50 | <Ms2ger> | Shouldn't new A() throw? |
| 14:50 | Ms2ger | didn't check |
| 14:54 | <tobie> | Ms2ger: oh, yes, of course. |
| 14:55 | <Ms2ger> | And I would hope new B() too, if it has a ctro |
| 14:55 | <tobie> | Ms2ger: Duh. Thanks |
| 14:55 | <Ms2ger> | Np :) |
| 14:55 | <tobie> | No, B wouldn't |
| 14:55 | <tobie> | (Why would it?) |
| 14:55 | <Ms2ger> | Oh |
| 14:55 | <Ms2ger> | I read B : A, not A : B |
| 15:07 | <tobie> | The fact that [Exposed] and [SecureContext] cater to both the interface and its members is confusing, imho |
| 15:07 | <tobie> | Especially once you have partials (and now mixins involved) |
| 15:07 | <tobie> | s/now/soon/ |
| 15:54 | <annevk> | tobie: partials and mixin just inherit (unless they are specifically restricted I suppose) |
| 15:55 | <annevk> | tobie: but specific restrictions should prolly only work for members |
| 16:00 | <annevk> | hsivonen: please look at https://github.com/whatwg/html/pull/3091 if you have the chance (requiring UTF-8 throughout HTML) |
| 17:31 | <jyasskin> | TabAtkins: Is there a way to attach an [algorithm] attribute to a ### header, or do I need to convert back to <h3 algorithm>? |
| 17:31 | <TabAtkins> | Currently no, you have to use HTML markup. Happy to accept patches to the markdown processor to add attr/class support alongside the id support. |
| 17:32 | <jyasskin> | Thx |
| 20:25 | <wanderview> | Domenic: JakeA: do you think its fair to write a WPT test that does a respondWith() a ReadableStream, provides a single chunk but does not close, and then tests if the window see the data from the intercepted fetch() Response.body? |
| 20:26 | <wanderview> | Domenic: JakeA: I think this should work, but in theory the spec could allow some re-buffering that might delay some/all of the data if only a single chunk is sent |
| 20:26 | <Domenic> | ehhhhh maybe with an appropriate comment saying that you could still fail this and be spec-conformant, and that if a browser has problems with the test they should file an issue to discuss |
| 20:26 | <wanderview> | I could write this as a firefox specific test instead of a WPT if we think that test is too strict |
| 20:26 | <Domenic> | Why not just close the stream? |
| 20:27 | <wanderview> | Domenic: because I specifically want to test that streaming works... for example, today chrome and firefox behavior differently on this test: https://html-sw-stream.glitch.me/ |
| 20:27 | <wanderview> | Domenic: firefox won't send any data to the outer window until the body is closed today |
| 20:28 | <wanderview> | I'm fixing that |
| 20:28 | <Domenic> | Hmmm |
| 20:28 | <Domenic> | I guess I see your point |
| 20:28 | <Domenic> | As long as it has appropriately liberal timeouts (e.g. the default WPT timeout) |
| 20:28 | <Domenic> | i.e. it's just like chunk received, then t.done() |
| 20:29 | <wanderview> | Domenic: I was planning to receive chunk, then postMessage() the SW to close the stream, cleanup and done |
| 20:29 | <Domenic> | oh, why? |
| 20:29 | <wanderview> | Domenic: to allow the service worker to gracefully cleanup instead of timing out |
| 20:30 | <Domenic> | I guess I don't understand enough about service workers to know why that would matter |
| 20:30 | <wanderview> | you can't unregister the service worker fully until its done processing any outstanding events... so if you only partially provide the body to respondWith() then the worker may live for a few minutes... that could screw up later tests |
| 20:31 | <wanderview> | I guess I have to waitUntil() to hold the worker alive since we haven't done any magic respondWith()+ReadableStream lifetime stuff |
| 21:35 | <wanderview> | Domenic: JakeA: FWIW this is the test I came up with: https://bugzilla.mozilla.org/page.cgi?id=splinter.html&bug=1204254&attachment=8914930 |