| 00:29 | <jwalden> | turf hot potato! the tc39/test262 people think that all tests involving document.all should go in w-p-t, but pretty much the entirety of https://github.com/jswalden/test262/commit/3eacab9399a6e500c3f1dd5df0fa450788306882 is testing ecma262 goo; is it actually likely that if I massaged that into w-p-t format, it would be accepted in a PR? |
| 00:30 | <jwalden> | (assume that the behavior of the goofy function being used there is just to return |document.all|) |
| 00:59 | <t3soro> | Who do I complain to about deficiencies in the EventSource API? |
| 01:01 | <t3soro> | It is like a first draft, cant set request headers, can't handle an error properly, or get HTTP status |
| 01:22 | <Domenic> | jwalden: definitely acceptable in WPT |
| 01:23 | <jwalden> | mm |
| 01:25 | <jwalden> | so, where to put these tests then |
| 01:26 | <jwalden> | shadow-dom/leaktests/html-collection.html html/infrastructure/common-dom-interfaces/collections/htmlallcollection.html html/obsolete/requirements-for-implementations/other-elements-attributes-and-apis/document-all.html html/dom/historical.html html/dom/interfaces.html are the existing document.all test locations, and none of them seem apropos |
| 01:33 | <jwalden> | maybe the (misspelled) js/behaviours |
| 01:34 | <Domenic> | Yeah I'd think anywhere under js/ |
| 01:41 | <jwalden> | boo, you didn't respond to my spelling trolling :-) |
| 01:55 | <MikeSmith> | t3soro: file issues at https://github.com/whatwg/html I guess |
| 01:58 | <t3soro> | Thanks @MikeSmith |
| 01:58 | <MikeSmith> | cheers |
| 01:58 | <MikeSmith> | jimklo: foolip might be able to help you when he’s around |
| 02:00 | <jimklo> | MikeSmith: thanks, I think I figured out a way, but it was definitely awkward. Required overwriting the prototype for TextTrack.addCue |
| 02:00 | <MikeSmith> | oh |
| 02:01 | <MikeSmith> | well I guess you rightly shouldn’t have to resort to that |
| 02:02 | <MikeSmith> | your use case sounds like it might merit you taking time to raise an issue at https://github.com/whatwg/html/issues |
| 02:03 | <jimklo> | MikeSmith: I understand why TextTrack.oncuechange does what it does, It just would be nice if instead of the track being the event target, an immutable list of active cues were available. The mutable live list just causes problems, since as time progresses the contents of the list changes |
| 02:04 | <jimklo> | so if you're trying to itterate the contents of TextTrack.activeCues - you can't exactly do that |
| 02:04 | <MikeSmith> | I see yeah |
| 02:06 | <jimklo> | I got what I needed done by adding a listener to the VTTCue.onstart/onfinish at the track level; so one doesn't need to individually listen to each individual cue event. |
| 02:07 | <jimklo> | basically what I need is the VTTCue.onstart/onfinish events available at the TextTrack level |
| 02:10 | <MikeSmith> | jimklo: so yeah that specifically sounds worthy of raising an issue, to see if you could get some browser-implementor interest in adding that |
| 02:11 | <jimklo> | I think the way I currently handle is probably the right approach, it's just the current API is a bit cumbersome. Sounds reasonable... I'll add an issue in GH |
| 02:11 | <MikeSmith> | but that said, if you do raise an issue, I recommend first describing what problem you’re trying to solve, and the propose a possible solution |
| 02:11 | <MikeSmith> | jimklo: super |
| 04:36 | <annevk> | domfarolino: ideally I think you would not be required to fetch such stylesheets at all |
| 04:37 | <annevk> | domfarolino: though maybe they do need to be fetched once the media starts matching; that would make sense and require more testing… |
| 06:57 | <domfarolino> | annevk: Hm i'm a little confused? Isn't the test to see if the browser only blocks rendering on the stylesheets that match the env, even though it fetches all? |
| 07:00 | <annevk> | domfarolino: yeah, but if you no longer block, that kinda begs the question what the behavior is instead |
| 07:01 | <domfarolino> | annevk: ohhhh...good point |
| 07:01 | <annevk> | domfarolino: I'm not entirely sure if figuring that out should block this PR though, but we should maybe have a follow-up issue of sorts |
| 07:05 | <domfarolino> | annevk: Ok that makes sense. Maybe it could be specified further in spec or something idk |
| 07:08 | <annevk> | domfarolino: I'm wondering if bz would consider changing the current setup in Firefox blocked on that |
| 07:08 | <annevk> | domfarolino: it seems that browsers that don't block scripts on loading all stylesheets, will have to start loading them as soon as there's a match of sorts, e.g., when the window is resized |
| 07:09 | <annevk> | domfarolino: though in other cases, e.g., "aural" as medium, you likely never have to fetch it |
| 07:21 | <domfarolino> | annevk: Hm wouldn't it be ideal if they loaded all sheets at once, just didn't block rendering on non-matching? If it didn't start "loading" until a match then you could resize the screen and not have styles applied, and thus have bad non-responsive looking site for as long as the network would take. Or am I missing something |
| 07:25 | <annevk> | domfarolino: well, but if the user never resizes you end up wasting bandwidth |
| 07:28 | <annevk> | domfarolino: anyway, it's worth looking into what UAs that don't block do for such a scenario |
| 07:30 | <MikeSmith> | annevk: I’m surprised the Chrome team hasn’t seen fit to fix their spec violation about sending TLS client certs in preflights |
| 07:30 | <MikeSmith> | as discussed at https://bugzilla.mozilla.org/show_bug.cgi?id=1019603 |
| 07:30 | <MikeSmith> | do you know if they even have an open bug for it? |
| 07:31 | <domfarolino> | annevk: True. But since browsers like firefox take that bandwidth by default now (by blocking on all sheets) users are probably more used to taking that bandwidth hit since that's all they've known, in exchange for a webapp that when resized, snaps into responsive styles immediately. |
| 07:31 | <domfarolino> | Yeah, I know chrome and safari don't block, and requests for the non-matching sheets are made at the same time as the matching ones |
| 07:31 | <domfarolino> | annevk: which I personally like but it's worth looking into deeper |
| 07:32 | <MikeSmith> | annevk: somebody else on stackoverflow ran into that and posted a question today https://stackoverflow.com/questions/46783506/why-is-the-tls-client-certificate-not-being-included-in-preflight-request-on-mos |
| 07:34 | <annevk> | MikeSmith: could you file a bug against Chrome? |
| 07:35 | <annevk> | MikeSmith: and maybe mention it in the Firefox bug? |
| 07:35 | <annevk> | MikeSmith: web-platform-tests doesn't have the chops to test this unfortunately |
| 07:35 | <annevk> | domfarolino: aah okay, so they have that behavior |
| 07:36 | <domfarolino> | annevk: Indeed, yeah sorry if that was unclear! Yeah they do that now :) |
| 07:38 | <annevk> | domfarolino: still gives the possibility of unstyled content when resizing early, but probably not that bad |
| 07:39 | <annevk> | domfarolino: do they avoid loading stylesheets that can never match? |
| 07:39 | <MikeSmith> | annevk: yeah will file it later today |
| 07:39 | <annevk> | MikeSmith: great thanks |
| 07:40 | <domfarolino> | annevk: yep that possibility exists for sure. That’s a good question hm I have no idea I may look into that in the next day or so given time allows. Interesting |
| 09:03 | <MikeSmith> | annevk: https://bugs.chromium.org/p/chromium/issues/detail?id=775438 |
| 09:28 | <annevk> | Ta! |
| 11:39 | <tobie> | What's the accepted antonym of blocklist? |
| 11:41 | <tobie> | annevk: ^ you're generally of good advice for these things |
| 11:42 | <tantek> | tobie, followings? |
| 11:42 | <Ms2ger> | allowlist? |
| 11:43 | <annevk> | tobie: safelist |
| 11:45 | <tobie> | yeah, I've see both allowlist and safelist, while some people claim whitelist is OK, only blacklist isn't (which seems weird, but the etymology might be completely different—see master branch vs master/slave db) |
| 11:45 | <tobie> | tantek: ? |
| 11:46 | <tantek> | tobie hard to suggest more nuance absent context |
| 11:48 | <tobie> | tantek: yeah, sorry: https://github.com/w3c/web-platform-tests/issues/7781#issuecomment-337205846 |
| 11:51 | <annevk> | tobie: HTML uses safe/block |
| 11:52 | <tantek> | tobie, wow that was quite a different context than I expected. interesting |
| 11:53 | <tobie> | tantek: heh |
| 11:53 | <tobie> | annevk: ty |
| 12:03 | <jgraham> | safe doesn't make sense in a non-security context |
| 12:40 | <tantek> | indeed, "safe" seems quite overloaded |
| 15:03 | <TabAtkins> | authlist/denylist has the nice property that the two words are the same length. |
| 15:04 | <TabAtkins> | I like allowlist/blocklist for the same reason. ^_^ |
| 15:44 | <bathos> | I am super guilty of choosing variable names with this property in mind in code all the time |
| 16:40 | <Mek> | annevk: any thoughts on https://github.com/w3c/web-platform-tests/pull/7848? |
| 16:45 | <wanderview> | Mek: I think he's on PTO for a few weeks |
| 16:46 | <Mek> | wanderview: ah, okay. he seemed active earlier, but in that case I won't bug him |
| 16:46 | <wanderview> | Mek: oh, I guess he was |
| 16:47 | <wanderview> | he works too much :-) |
| 19:14 | <KiChjang> | does anyone know if the fetch spec or the HTTP cache RFC specifies which headers to not cache? |
| 19:15 | <KiChjang> | and if so, where is it located? |
| 19:41 | <wanderview> | anyone here have Edge 16 yet? |
| 19:48 | <jsbell> | wanderview: I have it via browserstack |
| 19:51 | <wanderview> | jsbell: ah, interesting... thanks |
| 19:52 | <wanderview> | not sure I want to install an extension for the free trial |
| 20:02 | <jsbell> | wanderview: I forget what the extension adds, but I don't use it |
| 20:07 | <TabAtkins> | Do we have a server somewhere that is actually running the wpt test runner? |
| 20:08 | <wanderview> | jsbell: I have the windows update running... so I guess I'll get it soon |
| 20:41 | wanderview | wonders if windows will ask him to reboot or just cut him off mid-typing... |
| 20:54 | <TabAtkins> | Anyone around who can answer questions I have about slurping w-p-t metadata? |
| 20:54 | <gsnedders> | probably? |
| 20:54 | <TabAtkins> | I'm adding some Bikeshed feature for listing tests inline, and I want to: |
| 20:55 | <TabAtkins> | (a) verify that a given folder/testname exists (and hopefully do some levenshtein distance fixups to help with typos) |
| 20:55 | <TabAtkins> | (b) get the title and/or assertion for the test |
| 20:55 | <TabAtkins> | (c) link to a live version of the test |
| 20:55 | <TabAtkins> | (d) link to source of the test |
| 20:56 | <TabAtkins> | Happy to have to do some pulling/munging on my own (automatically) and just upload it somewhere in a more useful form for Bikeshed to consume. |
| 20:57 | <Mek> | maybe also link to results of the test on wpt.fyi? |
| 20:57 | <Mek> | (which itself already has links to source and live version of the test) |
| 20:57 | <nox> | TIL wpt.fyi |
| 20:58 | <TabAtkins> | Yes, that too. |
| 20:59 | <gsnedders> | TabAtkins: a) if you want to know if a given path is a test you need the manifest somewhere |
| 20:59 | <wanderview> | Mek: I wish it would atomically update... this stuff is confusing: https://wpt.fyi/service-workers/service-worker |
| 20:59 | <gsnedders> | TabAtkins: b) I don't think we store those anywhere at the momemt? |
| 20:59 | <wanderview> | I mean, I assume firefox has 0 passing because its updating results currently, etc |
| 21:00 | <TabAtkins> | gsnedders: k, if I can get the source address I can parse on my own and munge it into a datafile |
| 21:00 | <gsnedders> | wanderview: updating results should be atomic |
| 21:00 | <gsnedders> | TabAtkins: you run `./wpt manifest` and you get a MANIFEST.json somewhere |
| 21:00 | <wanderview> | gsnedders: then why do sometimes different browsers have zero results or clearly wrong results? |
| 21:01 | <gsnedders> | wanderview: there was some discussion about this somewhere recently, uh |
| 21:01 | <gsnedders> | wanderview: note Firefox's results for serviceworkers are all TIMEOUT |
| 21:01 | <gsnedders> | wanderview: (i.e., it's not missing results, it's accurately display the results it got) |
| 21:04 | <wanderview> | ok.... but we pass large numbers of the tests... so the TIMEOUT results seem incorrect to me |
| 21:05 | <gsnedders> | yeah, we're randomly getting a few too many TIMEOUT and ERROR in some browsers on some tests, and I don't know if we know why exactly. |
| 21:05 | <gsnedders> | TabAtkins: (see ./wpt manifest --help for more) |
| 21:07 | <gsnedders> | wanderview: https://github.com/w3c/wptdashboard/issues/162 |
| 21:08 | <wanderview> | thanks |
| 21:09 | <wanderview> | gsnedders: do you know if the test config sets any cookie related prefs? |
| 21:09 | <gsnedders> | TabAtkins: stepping back though, what's the goal here? how does this fit into the existing <link rel=help> stuff? |
| 21:10 | <gsnedders> | wanderview: it does the same as whatever wptrunner does |
| 21:10 | <wanderview> | ok |
| 21:16 | <TabAtkins> | gsnedders: The goal is that marking the *tests* to point to segments of the *spec* doesn't help with reviewing what parts of the spec need more testing. (It also requires a lot of inline markup anyway to add more anchors.) When reviewing a test to see if it's tested well, seems more useful to have the *spec* point to *tests* instead. (Was talking about this with fantasai over lunch - currently, she has to manually |
| 21:16 | <TabAtkins> | annotate things in reverse anyway when reviewing specs.) |
| 21:22 | <gsnedders> | TabAtkins: what makes that better than the current views we have based on the spec ToC? it sounds like it would add a lot of work onto the spec editor to maintain? |
| 21:26 | <TabAtkins> | gsnedders: Spec ToC-based isn't fine-grained enough, and still requires flipping back and forth between spec and the wpt view. Want to get these inline. |
| 21:27 | <TabAtkins> | The hope is also that it serves as an built-in reminder to write tests for things, so that a paragraph without tests following it looks obviously "wrong" in the source. |
| 21:30 | <TabAtkins> | (Requiring myself to remember to check a completely different view, unlinked by anything close to the spec, and then manually detangle how many tests are in each section and what they correspond to, to see if anything is currently untested, is not going to happen, and is a lot of work even if it does happen. Listing a few tests locally is something I can do *while writing tests*, and then it's there for me |
| 21:30 | <TabAtkins> | automatically and easy to review when editting.) |
| 21:31 | <manu> | TabAtkins gsnedders: Do either of you know a) Macros Caceres IRC nick (or if he's on here), b) how to inject polyfill code into web platform test stuff before the tests start running. |
| 21:31 | <TabAtkins> | It's `marcos` |
| 21:31 | <TabAtkins> | But he's not on here right now. |
| 21:32 | <manu> | k thx |
| 21:32 | <TabAtkins> | But as for "injecting", you can just put it into the test itself? No in-built way to, like, conditionally do that, I think. |
| 21:33 | <manu> | TabAtkins: well, we're trying to not modify the tests themselves... didn't know if there was a test setup phase in WPT where you could inject polyfill before the tests took over. |
| 21:34 | <TabAtkins> | Each test is just a separate HTML page that gets loaded and executed. |
| 21:36 | <manu> | TabAtkins: taaz knows more of the details on this as he's currently trying to work through it... he said the issue has more to do with waiting for the body to be ready, injecting the polyfill (because the Web Payments polyfill needs the body to be ready), and then allowing the promises in the test to then fire... it's a timing issue and we were wondering if anyone else had hit a problem like this writing polyfills that would pass WPT tests. (or if |
| 21:36 | <manu> | someone else had written a blog post about their experiences doing so). |
| 21:37 | <manu> | I'm guessing Marcos knows the magic incantations to make it work... we're trying the "edit the page HTML" approach now, but even then, you have to delay the test script being fired until after the polyfill is loaded. |
| 21:37 | <taaz> | there are some mentions of people doing polyfills, but it seems unclear if there's an easy way to insert such code for a whole dir of tests vs editing each file |
| 21:38 | <taaz> | so i was just trying to get one manually edited file to work |
| 21:38 | <Mek> | you could maybe modify your testharnessreport.js (which every test includes right after testharness.js), but you'd still have the problem of how to delay the actual tests... |
| 21:39 | <Mek> | maybe adding a start callback would do it, but then there is no guarantee that any particular test even has a body element... |
| 21:41 | <taaz> | the body issue is related to some internals in an rpc lib this polyfill is using. adding a dialog child node i think. i'm not sure how critical it is that that be done like that |
| 21:43 | <taaz> | just playing with payment-request/interfaces.https.html at the moment. seems the tests are run before DOMContentLoaded fires, which is causing the issue. |
| 21:44 | <taaz> | i can start wrapping tests to wait on things, but that's not really an option when trying to run all the test files |
| 22:03 | <TabAtkins> | gsnedders: Is the wpt manifest file format documented anywhere? |
| 22:05 | <TabAtkins> | (The "Writing Your Own Runner" section says to use `wpt manifest`, but doesn't explain how to read the output, and the JSON file is non-obvious.) |
| 22:06 | <gsnedders> | TabAtkins: no :) |
| 22:06 | <gsnedders> | TabAtkins: look at tools/manifest/manifest.py |
| 22:06 | <gsnedders> | TabAtkins: though even that isn't that clear |
| 22:06 | <TabAtkins> | I'm already looking at that, yeah. |
| 22:06 | <TabAtkins> | It does not illuminate. |
| 22:07 | <gsnedders> | basically you have obj['items'][testtype][path] = (tests: Array) |
| 22:07 | <gsnedders> | except testtype now also includes things like "support" |
| 22:09 | <TabAtkins> | Is it possible to write this down someplace. |
| 22:09 | <gsnedders> | tools/manifest/item.py it probably also useful here |
| 22:09 | <TabAtkins> | (If I can get shamed for not writing tests, others can get shamed for not writing docs.) |
| 22:10 | <gsnedders> | yeah, someone needs to actually document it somewhere |
| 22:12 | <TabAtkins> | It looks like all I maybe need is the `paths` array, because it contains all the names I want (and I can manually parse/reassemble those into the URLs I want)? |
| 22:14 | <TabAtkins> | (Also, I'd never seen that particular formatting for a dict comprehension before. Confused me for a second, but clever.) |
| 22:17 | <gsnedders> | (it's when it gets nested it becomes a mess) |
| 22:17 | <gsnedders> | (also I can't guarantee I understand all of this, fwiw) |
| 22:18 | <gsnedders> | like, idk what the paths array is :) |
| 22:23 | <TabAtkins> | So right now there are 7 "testtype" values. I have no idea what they mean. |
| 22:24 | <TabAtkins> | Maybe I can just pretend they're all equivalent, iterate them for their paths, and call it a day. |
| 22:25 | <TabAtkins> | (Types are "manual", "reftest", "reftest_node", "stub", "support", "testharness", and "wdtest".) |
| 23:06 | <Domenic> | TabAtkins: if it helps here is what I came up with for manipulating the manifest for my own purposes. https://github.com/tmpvar/jsdom/blob/master/test/web-platform-tests/wpt-manifest-utils.js |
| 23:07 | <Domenic> | (hmm, that value[[0]] looks wrong... I guess it works anyway because JavaScript) |
| 23:08 | <TabAtkins> | Ahahaha, I was just squinting at that and tabbed back to here to ask you about that. ^_^ |