| 12:42 | <annevk> | JakeA: for no-cors range requests, did you look at CORB? |
| 12:44 | <JakeA> | annevk: I haven't. Will catch up now. |
| 13:24 | <JakeA> | annevk: looks sensible. Doesn't get in the way of the range stuff I'm looking at. |
| 13:31 | <annevk> | K |
| 14:15 | <domfarolino> | With setTimeout(fn, 0) on a page in a parser-blocking script, should fn be invoked before the DOMContentLoaded event is fired? |
| 14:20 | <annevk> | domfarolino: timers are in a diff source, so don’t think so |
| 14:28 | <domfarolino> | annevk: Ok, because FF and Chrome seem to handle this differently (FF will run the timeout before DOMContentLoaded, chrome after) would you expect they should behave the same? |
| 14:29 | <annevk> | domfarolino: not necessarily, since it's up to the browser to determine relative priorities |
| 14:29 | <domfarolino> | Ok that's what I thought |
| 14:30 | <domfarolino> | I thought I remembered they could sort of do what they wanted wtih different sources |
| 14:30 | <annevk> | It's a little scary though since I'm not sure web developers take that kinda thing into account |
| 14:39 | <domfarolino> | annevk: How about https://gist.github.com/domfarolino/e0a19349f7134b9798e984c81138873c, would you expect the <link> load event fired to appear first in the console? |
| 14:40 | <domfarolino> | I use async script here that runs before the parser-blocking script to ensure that the event listeners are setup before DOMContentLoaded event has a chance to fire |
| 14:40 | <domfarolino> | Chrome won't show the <link> load event fired until after DOMContentLoaded, whereas FF is opposite |
| 14:41 | <annevk> | that one is tricky, it depends on whether the browser decides to wait for the stylesheet |
| 14:42 | gsnedders | gets tempted to try and write an extension to redirect people away from /TR/ again |
| 14:42 | <annevk> | I think in theory it should, although I could also see a case that it doesn't, unless the script asks for layout |
| 14:43 | <domfarolino> | annevk: Wait for the stylesheet to load before executing async script? |
| 14:44 | <annevk> | domfarolino: before executing the sync script |
| 14:45 | <domfarolino> | annevk: I believe all browsers block parser-blocking scripts from running before previously discovered stylesheets are loaded right now, which should "ensure" that the async script will run. |
| 14:46 | <domfarolino> | I can't see how, if both listeners got set before DOMContentLoaded, the DOMContentLoaded handler would be fired first |
| 14:46 | <domfarolino> | Because the parser-blocking script can only start running after the <link> load is loaded (and its event fired), it *must* come first right? |
| 14:47 | <annevk> | domfarolino: well, loaded will queue a task to fire |
| 14:47 | <annevk> | domfarolino: when that task runs depends on which source it's in |
| 14:47 | <annevk> | domfarolino: and how much priority that has for the browser |
| 14:48 | <domfarolino> | annevk: Right, but won't DOMContentLoaded and `<link> load` events be queued to the same source? |
| 14:48 | <domfarolino> | Or is that not mandated |
| 14:48 | <annevk> | domfarolino: maybe, some of this is a little vague |
| 14:48 | <domfarolino> | My assumption with this example was that they will be the same source, therefore should be well-ordered |
| 14:48 | <domfarolino> | Ahh ok |
| 14:48 | <annevk> | domfarolino: I haven't checked; if they go to the same source you'd be correct |
| 14:49 | <domfarolino> | annevk: I can dig around for it, I assume where we actually queue this task would be in HTML and not DOM right? |
| 14:51 | <annevk> | domfarolino: yup |
| 14:51 | <annevk> | (both) |
| 14:57 | <domfarolino> | Yeah so basically #queue-a-task says all tasks from a specific source must go to the same task queue, but nothing states that the DOMContentLoaded and other element `load` events originate from the same task source |
| 14:57 | <domfarolino> | And I guess there's not too much use in specifying that probably |
| 14:58 | <domfarolino> | I guess I just assumed they *must* originate from same source :( |
| 15:00 | <annevk> | domfarolino: we totally should specify their sources |
| 15:00 | <annevk> | Precisely so you can answer whether the order is defined |
| 15:00 | <domfarolino> | annevk: Ok initially that's what I thought but didn't know if that would be too restricting |
| 15:01 | <domfarolino> | Cool :) I can open an issue to discuss |
| 15:03 | <domfarolino> | Maybe specifying like a few key sources that must always exist, and giving impls freedom to add their own would be nice |
| 15:03 | <domfarolino> | Would allow us to fire these sorts of DOM events consistently from the same source to the same queue I guess |
| 15:08 | <annevk> | There is some of that already |
| 16:36 | <kereliuk> | Domenic: You can now send key events in WPT in firefox and chrome |
| 16:37 | <kereliuk> | Tab key should work... test_driver.send_keys(element, keys) |
| 16:41 | <gsnedders> | <3 |
| 16:45 | <annevk> | Oooh wow |
| 16:57 | <jgraham> | Incrementally adding this stuff should be mcuh easier now, assuming features you want are exposed in WebDriver |
| 16:57 | <jgraham> | If you want e.g. control over the GC or fake camera input, that's harder :) |
| 16:59 | <Domenic> | Is it keys = "tab" or keys = "\t" or...? |
| 16:59 | <jgraham> | Hahaha |
| 16:59 | <jgraham> | https://w3c.github.io/webdriver/webdriver-spec.html#keyboard-actions |
| 17:00 | <jgraham> | \uE004 |
| 17:02 | <domfarolino> | annevk: It seems at the end of these sections (https://html.spec.whatwg.org/multipage/semantics.html#obtaining-a-resource-from-a-link-element & https://html.spec.whatwg.org/multipage/parsing.html#the-end) the task source is specified as the DOM manipulation task source. So it appears this is specified, and Chrome doesn't follow it (a quick look of the source shows that the blink `LinkLoader` actually uses the networking |
| 17:02 | <domfarolino> | task source) so I'll refrain from filing a spec issue |
| 17:06 | <annevk> | domfarolino: what Chrome does seems a bit more reasonable though |
| 17:09 | <domfarolino> | annevk: I find it a little confusing personally. I would think the "load" event of a stylesheet that's blocking a script should be observable before the document is finished parsing. Because for the document to finish parsing, the stylesheet must be finished, we just can't tell from JS it seems |
| 17:10 | <annevk> | domfarolino: in this specific scenario it makes sense for them to use the same task source maybe, but generally network-driven events should use the networking task source |
| 17:13 | <domfarolino> | annevk: Yeah that too makes sense. I wonder if we should change the spec to fire load/error events from the networking source |
| 17:27 | <annevk> | domfarolino: I think so; def worth filing an issue on |
| 18:05 | <KiChjang> | is there a way to run a specific WPT on my browser? |
| 18:06 | <gsnedders> | KiChjang: http://w3c-test.org/? |
| 18:06 | <KiChjang> | oh nevermind, i found w3c-test.org |
| 18:07 | <KiChjang> | gsnedders: yeah, i knew of wpt.fyi and i just thought to look there |
| 18:10 | <KiChjang> | also, does anyone here maintain wpt.fyi? |
| 18:10 | <KiChjang> | the links to w3c-test.org doesn't quite work, because apparently w3c-test.org doesn't serve over SSL and all the links in wpt.fyi uses HTTPS |
| 18:12 | <jgraham> | jugglinmike: ^ |
| 18:13 | <gsnedders> | KiChjang: it should work over HTTPS? though it's frequently super-slow for some reason |
| 18:13 | <gsnedders> | yeah I just loaded it over HTTPS |
| 18:13 | <gsnedders> | but yeah, most of the links (i.e., all except tests that rely on HTTPS) should point at HTTP |
| 18:13 | <KiChjang> | ah, perhaps it was indeed super slow |
| 18:15 | <gsnedders> | KiChjang: https://github.com/w3c/wptdashboard/issues/532 |