| 07:43 | <FND> | hi - if I have nested custom elements (`foo-main > foo-sub`, server-rendered HTML), can I rely on a specific order of `connectedCallback`s firing? |
| 07:43 | <FND> | empirically, it seems that nested components are initialized first |
| 07:54 | <annevk> | FND: I think in-out is defined, yes, but you shouldn't rely on that as the tree can be manipulated at random |
| 07:55 | <FND> | yeah, I'm aware of the latter - but in this case, the sub-components are effectively internal, so under my control |
| 07:55 | <FND> | I couldn't find anything on that in-out order, but I'll just take your authority for it :) |
| 07:56 | <annevk> | I wouldn't, I just recall this being discussed |
| 07:59 | <FND> | fair enough - I'll keep searching for an authoritative reference then, thanks though |
| 08:00 | <annevk> | FND: it should be defined between https://dom.spec.whatwg.org/ and https://html.spec.whatwg.org/multipage/ |
| 08:00 | <annevk> | FND: in particular I guess you want to study the parser section of HTML |
| 08:00 | <annevk> | (and follow the links from there) |
| 08:01 | <FND> | excellent, will do (after I've checked out of my hotel though, so bbl) |
| 08:03 | <MikeSmith> | annevk: did anybody get you a solution to that that WPT port thing from yesterday? |
| 08:04 | <annevk> | MikeSmith: "use JavaScript" is what I got |
| 08:05 | <MikeSmith> | hmm that’s not a terrifically satisfying answer |
| 08:08 | <annevk> | MikeSmith: given WPT staff lack of time, I think it's all we got until someone learns more about wptserve and fixes it somehow |
| 08:08 | <annevk> | MikeSmith: you basically want something like {{hostport}} that leaves out the port if it happens to be the default |
| 08:09 | <annevk> | MikeSmith: and a standardized JavaScript library to deal with cross-origin tests wouldn't be bad to have either |
| 08:10 | <MikeSmith> | yeah that cross-origin library thing is more work of course but the port thing would not be a big level of effort |
| 08:10 | <MikeSmith> | though I guess once I start saying that somebody will suggest I just implement it then |
| 08:10 | <annevk> | wptserve also lacks instructions for how to run it and test it which makes it a little scary |
| 08:11 | <MikeSmith> | there is not way to test it |
| 08:11 | <MikeSmith> | well, we have not tests at least |
| 08:11 | <MikeSmith> | *no tests |
| 08:11 | <annevk> | It seems to have some tests when I browsed through the code |
| 08:11 | <annevk> | But I didn't add any when I added support for raw_headers and jgraham didn't seem to care either |
| 08:11 | <MikeSmith> | oh well then that’s better than I though |
| 08:12 | <annevk> | Because it was very much unclear how they'd work |
| 08:13 | <MikeSmith> | I’ve never provided tests for changes I make to WPT infrastructure, nor required anybody else to when I review PRs |
| 08:14 | <MikeSmith> | which is unfortunate I guess |
| 08:14 | <Ms2ger> | Both wptserve and wpt-tools have a bunch |
| 08:15 | <annevk> | A bunch? |
| 08:15 | <annevk> | I saw like six tests |
| 08:28 | <tobie> | Neither testharness nor idlharness have tests either, fwiw. |
| 08:29 | <tobie> | I'm not sure that anyone has a clear idea of what the latter precisely tests, tbh. |
| 08:29 | <annevk> | idlharness tests a whole bunch |
| 08:30 | <annevk> | tobie: see http://w3c-test.org/XMLHttpRequest/interfaces.html for instance |
| 08:33 | <tobie> | annevk: a bunch seems to be the unit of measure over here. |
| 08:33 | <annevk> | tobie: making sure the object is properly exposed to JavaScript is a good thing to test |
| 08:34 | <tobie> | annevk: I gather from your discussion with Ms2ger above that a bunch is > 6 |
| 08:34 | <annevk> | tobie: I think we're getting 1000s of individual tests from idlharness |
| 08:35 | <annevk> | tobie: probably more |
| 08:35 | <tobie> | annevk: sounds like my morning humor is falling short. |
| 08:35 | <annevk> | tobie: heh |
| 08:36 | <tobie> | annevk: dug into idlharness earlier this month. |
| 08:36 | <tobie> | annevk: it's very hard to figure out what's going on. |
| 08:37 | <tobie> | annevk: and given there are no tests for it, it's very hard to have a sense of what it's trying to achieve and how. |
| 08:38 | <tobie> | annevk: for example, how it's dealing with [SecureContext] and [Expose]. |
| 08:38 | <tobie> | annevk: and how that ties into wpt-serve. |
| 08:39 | <annevk> | wptserve is the server component so that's kinda separate |
| 08:40 | <annevk> | I don't really know idlharness details though |
| 08:43 | <MikeSmith> | I guess the idlharness code it not a great model of clarity |
| 08:43 | <tobie> | annevk: well, it's not so separate. You need some communication between the two if you want to test SecureContext (behavior for both https and http) and Expose (ie test within workers and service workers) and wire the whole thing up. |
| 08:44 | <MikeSmith> | I’ve only just hacked stuff into it when I needed specific tests to run for IDL parts it did not support yet |
| 08:44 | <tobie> | MikeSmith: likewise. |
| 08:56 | <MikeSmith> | thing is, we don’t have a real owner for idlharness now |
| 09:12 | <annevk> | MikeSmith: https://github.com/w3c/web-platform-tests/pull/4801 |
| 09:45 | <MikeSmith> | annevk: responded https://github.com/w3c/web-platform-tests/pull/4801#issuecomment-281619610 |
| 10:06 | <jgraham> | What was the port issue? |
| 10:06 | <jgraham> | re: testing testharness.js it would require something like selenium |
| 10:06 | <jgraham> | Which is quite high overhead |
| 10:08 | <annevk> | jgraham: {{host}}:{{[http][0]}} doesn't work sometimes as it emits the default port (e.g., on w3c-test.org) |
| 10:08 | <annevk> | jgraham: so you want something like {{hostport}} instead |
| 10:08 | <jgraham> | Well that doesn't quite work either, since there are multiple ports |
| 10:09 | <annevk> | jgraham: it would help with https://github.com/w3c/web-platform-tests/issues/2618 at least |
| 10:10 | <annevk> | jgraham: I guess I could rewrite the test somehow though |
| 10:11 | <annevk> | jgraham: e.g., (new URL("/", location.href)).href would go a long way there |
| 10:11 | <jgraham> | My preferred solution at this point is to say that the tests don't work on a default port, because that particular brokenness affects a bunch of tests |
| 10:11 | <annevk> | jgraham: but that sucks for preview |
| 10:12 | <annevk> | jgraham: I guess then redirect w3c-test:80 to w3c-test:800 |
| 10:12 | <jgraham> | And even supporting a default port doesn't actually fix the problem where sometimes you want to check default and non-default port behaviour |
| 10:12 | <jgraham> | Unless you *require* a default port, which is hard because it requires sudo to start the server |
| 10:12 | <jgraham> | annevk: Yeah, I was assuming moving w3c-test.org to serve on port 8000 or wahtever |
| 10:16 | <tobie> | jgraham: you could use something like karma (https://karma-runner.github.io/1.0/index.html). |
| 10:16 | <jgraham> | But if there's a strong desire to have hostport[http[0]] or similar then it is implementable |
| 10:18 | <jgraham> | tobie: I don't know if that's meaningfully different from using WebDriver |
| 10:19 | <jgraham> | Except it has a built-in server which might actually be a bad thing for our needs |
| 10:28 | <mkwst_> | jgraham: Speaking of default ports, we can't really test things like HSTS or upgrade-insecure-requests when the server isn't running on 80/443. |
| 10:29 | <mkwst_> | I don't have an answer, but it's somewhat annoying. :/ |
| 10:32 | <tobie> | jgraham: I dunno, you mentioned selenium was quite high overhead. Karma's rather simple to setup. |
| 10:39 | <jgraham> | tobie: Well it still needs a real browser running (or something like Phantom which is a a real old version of WebKit), and still requires a webserver running, so I'm not sure which part of the complexity it addresses. "pip install selenium" is also pretty easy to set up, ignoring all the other stuff. |
| 10:39 | <jgraham> | mkwst_: Yeah. It would be nice if there was a way to override the default default ports in browsers or something, just for testing purposes |
| 10:40 | <mkwst_> | I suspect you'll find that that's non-trivial. |
| 10:40 | <jgraham> | But maybe that also doesn't work for some reason… maybe eventually we will just have to require root to run the tests. But that seems like it would cause a *lot* of pain |
| 10:40 | <mkwst_> | I know we have "80" and "443" hard-coded all over the place. |
| 10:40 | <mkwst_> | (In Chrome/Blink) |
| 10:40 | <jgraham> | Yeah, makes sense |
| 10:41 | <mkwst_> | Maybe worth cleaning up from a theoretical perspective, though! |
| 10:41 | <mkwst_> | GoodFirstBug. |
| 10:42 | <annevk> | They are hard-coded in standards as well... |
| 10:49 | <tobie> | jgraham: Travis lets you run tests on Firefox (maybe others?). Karma just plugs into that. |
| 10:50 | <jgraham> | Firefox on travis is very very old iirc |
| 10:52 | <Ms2ger> | jgraham, SpiderMonkey people are looking at running th.js tests in the js shell; we could perhaps use that for tests |
| 10:53 | <jgraham> | Ms2ger: Workers |
| 10:53 | <jgraham> | I assume that they wouldn't work |
| 10:53 | <Ms2ger> | Sure |
| 10:54 | <Ms2ger> | I guess it depends on what you want to test exactly |
| 10:54 | <jgraham> | Well something is better than nothing ofc, but since most of the complexity is around support for multiple globals and so on… |
| 10:55 | <jgraham> | Or, not multiple globals, but multiple possible global objects |
| 10:56 | <Ms2ger> | I think th.js is still very much in the "anything at all" stage :) |
| 11:02 | <tobie> | Likewise. |
| 11:02 | <tobie> | I'd just like to write a bunch of basic tests for idlharness just to check my assumptions from reading the program. |
| 11:23 | <annevk> | gsnedders: turns out we do hit the problem you mentioned: https://github.com/whatwg/meta/issues/20 |
| 13:30 | <annevk> | hsivonen_: did you see https://github.com/w3c/web-platform-tests/labels/encoding? |
| 13:30 | <annevk> | hsivonen_: there's apparently quite a few encoding tests |
| 14:14 | <hsivonen_> | annevk: I saw them last year, but the encoder tests weren't usable in Firefox before I fixed URL query encoding encoder |
| 14:14 | <hsivonen_> | annevk: and then I forgot to re-examine the tests |
| 14:14 | <hsivonen> | I'll take another look once I have encoding_rs running in Gecko |
| 14:15 | <annevk> | hsivonen: sounds good, ping if you want help at that point |
| 14:15 | <annevk> | I'll wait until then |
| 14:16 | <hsivonen> | annevk: ok |
| 14:32 | <JakeA> | annevk: something seems to have broken with the formatting https://fetch.spec.whatwg.org/#fetch-method |
| 14:32 | <annevk> | JakeA: thanks, it's missing a leading newline, some weird Bikeshed thing |
| 14:33 | <annevk> | JakeA: I'll fix it as part of a PR I'm working on |
| 14:33 | <JakeA> | Cheers! |
| 17:50 | <wanderview> | JakeA: do you think it make sense to expose an "intercepting" or "synthesizing" values in FetchState? to represent that the request is being handled by a service worker? |
| 17:54 | <JakeA> | wanderview: would that be an alternative to the "requesting" phase? |
| 17:54 | <wanderview> | also, I hope we can spec the priority stuff after landing cancelation |
| 17:54 | <JakeA> | wanderview: yeah, I think the current plan would allow us to land just cancellation, but not observation & priorities |
| 17:54 | <wanderview> | JakeA: well, I thought requesting implied actually opening a connection to the server or hitting the http cache |
| 17:56 | <JakeA> | wanderview: I maybe need to work on the naming. I was thinking "requesting" was before headers, and "responding" was until the body was read or connection was closed. My aim here is to allow these values to be used on no-cors without exposing anything new |
| 18:13 | <wanderview> | JakeA: right, but there are multiple stages "before headers" |
| 18:14 | <wanderview> | JakeA: I guess my question was if it would be useful to expose that level of granularity... both here and in performance timing data |
| 18:15 | <JakeA> | wanderview: yeah, not against it. We can just use something less granular for no-cors |
| 18:17 | <wanderview> | JakeA: I guess maybe its good to be conservative for now... just something I was thinking about |
| 18:17 | <wanderview> | sometimes I want to expose all the things |
| 18:18 | <wanderview> | like, I was thinking we could in theory expose something like Client.referrerPolicy or Client.contentSecurityPolicy to inspect those settings on a Client |
| 18:18 | <JakeA> | wanderview: I'm just nervous of creating new HEIST stuff |
| 18:18 | <wanderview> | but probably doesn't make sense without a use case |
| 18:18 | <wanderview> | sure |
| 18:36 | <wanderview> | JakeA: thanks for fleshing out the API |
| 18:41 | <JakeA> | Cheers! Finally got round to it 😀 |
| 19:51 | <Domenic> | I guess a signal is what cancelable promises called a token |
| 20:38 | <TabAtkins> | Domenic: Yes; "signal" is the async contexts I've seen it is just "a promise, but we only pay attention to when it fulfills, not what it fulfills to". |
| 20:59 | <jyasskin> | TabAtkins: Does Shepherd get confused when a data-lt attribute is split across lines, like in https://html.spec.whatwg.org/multipage/browsers.html#is-a-registrable-domain-suffix-of-or-is-equal-to? |
| 20:59 | <TabAtkins> | It *shouldn't* - whitespace gets normalized to single spaces. |
| 20:59 | <TabAtkins> | But are you experiencing an issue? |
| 21:00 | <Domenic> | It might just not have indexed that yet, it was merged this morning IIRC? |
| 21:00 | <jyasskin> | 'k. `bikeshed refs --text 'is a registrable domain suffix of or is equal to'` isn't returning any results, but it's totally possible the index is just out of date. |
| 21:06 | <TabAtkins> | let me go check |
| 21:07 | <jyasskin> | Thanks! <3 TabAtkins |
| 21:11 | <TabAtkins> | Yeah, def not in the db yet. |