| 09:32 | <tobie> | Do we have any examples of inheriting NoInterfaceObjects? I think not, but I want to be sure. |
| 09:33 | <Ms2ger> | There used to be one in XHR |
| 09:34 | <Ms2ger> | I think we removed it because NoInterfaceObject should only be used on mixins |
| 09:35 | <tobie> | Ms2ger: so the reason I'm asking is because I'm busy adding dedicated mixin syntax right now |
| 09:36 | <Ms2ger> | Then we should not need NoInterfaceObject anymore |
| 09:36 | <tobie> | Ms2ger: and I want to be sure I can eschew inheritance altogether. |
| 09:36 | <Ms2ger> | Oh, inheriting mixins? Dunno |
| 09:36 | <tobie> | Ms2ger: we still need it for a bunch of things. But we'll call it LegacyNoInterfaceObjct |
| 09:38 | <tobie> | E.g. this guy: https://www.w3.org/TR/geolocation-API/#geolocation |
| 09:39 | <tobie> | Ms2ger: well, if there are no inheriting NoInterfaceObjects right now, we can keep things saner by preventing them altogether in the mixin design |
| 09:40 | <Ms2ger> | Makes sense |
| 09:43 | <tobie> | The follow-up question is whether there are any mixins with anything other than regular attributes and operations |
| 09:43 | <tobie> | i.e. statics? specials ops? etc. |
| 10:05 | <tobie> | Ms2ger: is moz-central still mirrored on Git somewhere? |
| 10:06 | <Ms2ger> | https://github.com/mozilla/gecko-dev |
| 10:11 | <tobie> | Ms2ger: ta |
| 10:11 | gsnedders | always want to know why it isn't mozilla-central but rather gecko-dev |
| 10:13 | <Ms2ger> | Np |
| 10:13 | <tobie> | gsnedders: to promote irc interactions between Mozillians and non-Mozillians |
| 10:14 | <tobie> | gsnedders: works like a charm |
| 10:14 | <tobie> | downloading gecko-dev is the new "waiting for the code to compile" |
| 11:06 | <zcorpan> | foolip: I'll let you merge the quirks PRs |
| 12:11 | zcorpan | finds files under demos/ with <!DOCTYPE html PUBLIC "-//WHATWG//NONSGML HTML5//EN"> |
| 12:21 | <Ms2ger> | Nice |
| 12:33 | <gsnedders> | where does that PUBLIC ID even come from? |
| 12:34 | <oal_> | Any ideas why Chrome refuses to accept "793" and shows a value that "793.01" is valid when using an <input type="number"> field? |
| 12:42 | <ondras> | hm |
| 12:42 | <ondras> | The server at wiki.ecmascript.org is taking too long to respond. |
| 13:30 | <Domenic> | tobie: sounds like you're on the right track with mixins. I do not know of any statics or special ops yet, so we can start conservative. |
| 13:32 | <tobie> | Domenic: yeah, turns out awk + grep do wonders for that kind of research |
| 13:32 | <Domenic> | Special ops and even statics don't seem problematic in theory. But why make it more complex than it needs to be, IMO. |
| 13:33 | <tobie> | Domenic: yeah, this is the occasion to enforce cleaner design, so let's do it |
| 13:34 | <tobie> | Domenic: as you said, we can always add more stuff if there are compelling use cases |
| 13:36 | <wanderview> | JakeA: are there any real blockers to landing the fetch abort PR? |
| 13:41 | <JakeA> | wanderview: there were some additional comments, but I haven't gone through them yet. It feels close. Really close. |
| 13:41 | <wanderview> | yea, we already have the tests |
| 13:42 | <wanderview> | JakeA: do you think there is any reason to ship Abort API without the fetch integration? I think no, but baku was proposing it |
| 13:43 | <JakeA> | wanderview: there are other specs interested in using it, but I don't see a huge benefit. I guess there's a danger that developers would think !!self.AbortController means fetch abort is supported |
| 13:44 | <wanderview> | yea |
| 13:44 | <wanderview> | just like ReadableStream! |
| 14:02 | <wanderview> | JakeA: so we are having trouble getting this test case to pass with the proposed webidl: https://hg.mozilla.org/integration/mozilla-inbound/file/92692c9a4f1e/testing/web-platform/meta/fetch/api/abort/general-serviceworker.https.html.ini#l3 |
| 14:02 | <wanderview> | JakeA: baku tells me he has to change RequestInit.signal to `AbortSignal?` instead of `AbortSignal` for it to work |
| 14:03 | <JakeA> | wanderview: this is a mistake in the test, thanks for flagging it |
| 14:03 | <JakeA> | wanderview: I'll fix that now |
| 14:05 | <wanderview> | JakeA: thanks! |
| 14:05 | <wanderview> | JakeA: also, is the timing of this test guaranteed? http://searchfox.org/mozilla-central/source/testing/web-platform/tests/fetch/api/abort/general.js#439 |
| 14:05 | <wanderview> | I don't understand how you can ensure the empty.txt file loads through the network stack before the abort() happens |
| 14:08 | <JakeA> | wanderview: hmm, I thought that since it had an empty body it'd be done by the time headers arrived, since that's all there was. I could clone the response and await responseClone.text(), would that help? |
| 14:08 | <wanderview> | JakeA: I mean, is there something in the spec that guarantees the network stack will detect the body is complete when it completes receiving the headers and resolves the fetch() promise? we have some async steps that close the body shortly after, but its a separate task |
| 14:09 | <JakeA> | wanderview: I guess teeing the body stream and exhausting it would be better? |
| 14:10 | <JakeA> | no wait, teeing wouldn't work |
| 14:10 | <JakeA> | await response.clone().text() |
| 14:10 | <wanderview> | JakeA: I don't understand what you are trying to test here... that a complete empty stream is not errored on abort? |
| 14:13 | <JakeA> | wanderview: going to double check how I'm using streams here. A previous draft treated things like the readable canceling, but it was changed to erroring. Going to double check the assumptions in that test |
| 14:14 | <JakeA> | no, it's still cancelling, I remembered wrong. Actually, I'll stop piping brain to IRC until I'm sure |
| 14:18 | <zcorpan> | I... think I've managed to confuse myself https://github.com/whatwg/html/issues/2973 |
| 14:18 | <wanderview> | JakeA: well, I think we are not going to block shipping on this test for now... right now we fail it |
| 14:19 | <JakeA> | wanderview: it's definitely an edge case |
| 14:20 | <wanderview> | JakeA: I do want this one fixed before shipping, though: https://bugzilla.mozilla.org/show_bug.cgi?id=1394102 |
| 14:20 | <wanderview> | JakeA: and unfortunately I don't think there is a WPT test for it yet |
| 14:21 | <wanderview> | JakeA: is this something you want to add or do you want me to have baku write the WPT test and upstream it through gecko? |
| 14:21 | <JakeA> | wanderview: happy for baku to do it |
| 14:21 | <wanderview> | ok |
| 14:21 | <JakeA> | sorry there wasn't a test already |
| 14:22 | <wanderview> | np |
| 14:22 | <wanderview> | JakeA: at least in our implementation we often lose data on Request going to FetchEvent.request... because of how we have to convert to an itnernal network thing and then back to Request... so its a common bug I've started to look for |
| 14:27 | <wanderview> | JakeA: honestly its surprising how many of the tests work correctly without having an implementation to run them against initially |
| 14:28 | <JakeA> | wanderview: I built *the worst* polyfill so I could kinda test some of the tests |
| 14:28 | <JakeA> | but yeah, it helped catch mistakes |
| 14:29 | <wanderview> | JakeA: any chance you could rubber stamp this WPT change to SW tests? https://github.com/w3c/web-platform-tests/pull/6745 |
| 14:30 | <wanderview> | test bug on the uplift from blink that wasn't caught because blink doesn't pass the test yet |
| 14:31 | <JakeA> | wanderview: merged! |
| 14:31 | <wanderview> | thanks! |
| 14:38 | <wanderview> | JakeA: I'm always conflicted about whether to do WPT changes in gecko and then pester jgraham to sync them... or to do an upstream PR directly |
| 14:39 | <JakeA> | I HATH RETURN'D FROM THE DEPTHS OF THE STREAMS SPEC |
| 14:40 | <JakeA> | wanderview: ok, so, https://streams.spec.whatwg.org/#readable-stream-default-controller-close - this is called when the stream is closed |
| 14:41 | <JakeA> | wanderview: Usually, the closing operation is in effect added to the end of a queue, behind data that's already been added |
| 14:42 | <JakeA> | So the stream doesn't become actually closed until something reads all the data |
| 14:42 | <JakeA> | However, if there's no data, the stream is closed immediately |
| 14:42 | <JakeA> | And once it's closed, it can't error |
| 14:43 | <JakeA> | So, if a byte is added to the stream, then it's closed, that stream can still error as the result of aborting |
| 14:43 | <wanderview> | JakeA: sure, but in fetch when does it make the determination that there is no data? |
| 14:44 | <JakeA> | wanderview: yeah, the timing of that test is broken. It assumes close() has already been called, which may not be the case |
| 14:45 | <wanderview> | perfect! |
| 14:46 | <JakeA> | wanderview: I'm trying to test that a closed response stream with nothing in the queue will not reject with AbortError |
| 14:46 | <JakeA> | but I'm not sure it's testable |
| 14:46 | <JakeA> | outside of a controlled streams test of course |
| 14:48 | <JakeA> | wanderview: would awaiting response.clone().text() sort it, or is that still unreliable? |
| 14:49 | <wanderview> | JakeA: I believe it would avoid the race, I'm just not 100% sure if aborting at that point tests what you want |
| 14:49 | <wanderview> | I guess it does? |
| 15:15 | <JakeA> | wanderview: the test would clone, read all of the response, abort, then read from the original request's stream |
| 15:16 | <JakeA> | wanderview: that means the browser would now have the whole response, but I guess it doesn't guarantee that the stream object has closed |
| 15:21 | <JakeA> | Domenic: If a response is empty, is response.body.getReader().closed guaranteed to fulfill? |
| 15:21 | <Domenic> | Pretty sure yes |
| 15:22 | <JakeA> | The underlying source may be waiting on a pull to call controller.close(), but I guess that will always happen, even without reader.read() |
| 15:58 | <JakeA> | wanderview: ok so I got distracted and didn't change those tests, but it's on my todos for tomorrow |
| 16:10 | <wanderview> | np, thanks |
| 20:46 | <gsnedders> | TabAtkins: how is perf under pypy nowadays? |
| 20:46 | <TabAtkins> | Not a clue. |
| 21:04 | <wanderview> | I wish WPT tests would include comments about the intent of the test... sometimes its hard to infer what its trying to test |
| 21:04 | <wanderview> | like this test: https://github.com/w3c/web-platform-tests/blob/master/service-workers/service-worker/navigation-redirect-body.https.html |
| 21:05 | <wanderview> | I think its trying to verify the POST gets converted to a GET on the redirect, but its a bit vague |
| 21:05 | <gsnedders> | oh god the number of arguments we've had over that |
| 21:06 | <gsnedders> | because 99% of the time a fair number of people go "my tests are obvious what they're testing and I'm not going back and adding comments so you're not getting them" |
| 21:07 | <wanderview> | gsnedders: I'm not saying to go back and add them... but we could encourage people to document future tests |
| 21:07 | <wanderview> | and unfortunately a lot of tests are not obvious when they are spread across main window, an iframe, a service worker event handler, and a .py server script |
| 21:11 | <wanderview> | JakeA: with foreign fetch going away, are we keeping link registration of service workers? I assume so, but they were added together so wasn't sure |