w3 :: #testing

14 Mar 2017
08:25zcorpanhttps://github.com/w3c/web-platform-tests/pull/5131#issuecomment-286174998 - apparently it doesn't work to do `foo \`bar\` baz`
09:06jgrahamgsnedders: https://treeherder.mozilla.org/#/jobs?repo=try&revision=c6a5c37f11890ed029051788147c5f71f6fe2c08 btw
09:06jgrahamSurprisingly non-terrible (I mean lots failed, obviously)
09:06annevkThe documentation I landed yesterday was wrong btw
09:06annevkYou need a colon after // META
09:07annevkI'll PR later
09:10annevkjgraham: I ran into a limitation of .any.js
09:10annevkjgraham: it doesn't work if you need sub
09:13annevkjgraham: I tried .sub.any.js fwiw
09:25jgrahamannevk: I made a patch for that yesterday
09:25annevkjgraham: docs or sub?
09:31Ms2gerjgraham, reviewed https://github.com/w3c/wptserve/pull/114
09:32jgrahamannevk: sub
09:46annevkAh cool, I guess I can wait for that to land
09:46annevkAnother thing that would be cool is to make the directory listing a little smarter and also list the auto-generated .html and .worker.html resources
09:46annevkMaybe between parenthesis after the .any.js resource since I believe you stated once you'd rather not make the default listing "magical"
10:35annevkjgraham: if I write a patch for directory listing, would you take it?
10:37annevkI guess my main problem is that I wouldn't quite know how to test my patch
11:25jgrahamannevk: Would happily take it. THe problem such as it is is that it would mix logic specific to wpt into general wptserve which is occasionally used for other things
11:26annevkjgraham: ah good point, I don't know how to abstract around that
11:26jgrahamannevk: So I have an idea. I'll try if I have a little time
11:27jgrahamI agree taht the current situation is a little annoying
11:34annevkFWIW, I'm doing some triage on open PRs
12:01jgrahamannevk: Thanks!
12:33gsneddersjgraham: what am I looking at with treeherder and what do I care? (I know it's csswg_test_merged, but, idk what I'm looking for or anything)
12:36jgrahamgsnedders: Nothing in particular, just that it worked, for small values of worked
14:20annevkWhy do we both have docs and type:documentation?
14:20annevkAs labels
14:22jgrahamNo idea
14:22jgrahamOh well docs probably comes from the directory name
14:22jgraham and type:documentation predates that
14:22jgrahamHappy to just use docs now
14:23jgrahamBTW I have a fix for the directory listings, I think
14:23annevkOkay, I'm using that
14:28gsneddersjgraham: the fact they don't actually list the generated files or what?
14:28gsneddersannevk: and yeah, AFAIK it's what jgraham said
14:30jgrahamgsnedders: Yeah, although now for some reason it's listing some genenerated files twice :/
14:33jgrahamOh, this might not be the best design
14:37Ms2gerStory of your life?
14:39jgrahamWell perhaps
14:42gsneddersso what are we doing with csswg-test contributors and push access to wpt?
14:43annevkweb-platform-tests issues without labels :/
14:44* annevk goes through them all and finds numerous undiscovered XMLHttpRequest issues
14:45gsneddersannevk: yeah, auto-labelling issues is comparatively hard
14:47annevkGiven the rate at which these are filed I might be able to keep up myself, it's just doing it retroactively that's more work
14:47annevkOr at least more work in one go
14:49gsneddersyeah, we really need someone who just keeps up and makes sure everything gets labelled
14:50annevkI'm on page 6 of 11 doing that
14:50zcorpangsnedders: csswg-testers team is just 6 people (excluding bots and pending invitations)
14:50annevkPlus also some closing / giving advice
14:54gsnedderszcorpan: csswg-reviewers is 12, seemingly
14:54gsnedderszcorpan: but I don't have access to see who is in it
14:54gsnedderszcorpan: and there's also the csswg team
14:56jgrahamgsnedders: Have a conversation with MikeSmith
14:56jgrahamThey can all be grandfathered in
14:57gsneddersMs2ger: any opnions?
14:57Ms2gerI would hold off until people ask, personally
14:58* gsnedders is marginally inclined to go along with that
14:59jgrahamThat also works
15:00zcorpangsnedders: you can check the top contributors in csswg-test
15:04annevkgsnedders: I'm guessing https://github.com/w3c/web-platform-tests/issues/2374 is a duplicate of a newer issue that I didn't spot?
15:10gsneddersannevk: we don't have a great issue
15:10gsneddersannevk: https://github.com/w3c/csswg-test/issues/1102 is the closest
15:11annevkgsnedders: ta, closed this one for that
15:42annevkAlright, I'm going to watch web-platform-tests and try to tag all the things
15:42annevkI'll try to let this channel know if it becomes too much
15:44jgrahamannevk: That's amazing, thanks
15:45annevkI think I also tagged all existing issues
15:45annevkThere's a lot of work for html/ :/
15:49* Silver slaps jeremychen around a bit with a large fishbot
16:13gsnedderszcorpan: can you see if there was ever anything about monospace font-size being automatically adjusted ever reported on Presto?
16:13gsnedderszcorpan: e.g., http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4945
16:38gsneddersjgraham: https://github.com/w3c/wpt-tools/pull/180#issuecomment-286275285
16:49gsneddersjgraham: I've responded again asking what you want
17:00gsneddersjgraham: (i.e., https://github.com/w3c/wpt-tools/pull/180#issuecomment-286483275)
17:59DomenicSo what's the plan for all the "replace setTimeout" PRs?
18:22annevkReplace them with ones that work?
18:22annevkSuspect gsnedders should actually work on css integration
19:10gsneddersDomenic, annevk: I basically split them out frm jgraham's old PR when they applied without merge conflicts in the hope some of them could land soon
19:10Domenicgsnedders: but are they ever going to land, or just sit in the PR queue?
19:11jgrahamDomenic: They will land if someone reviews them
19:11DomenicAh, well then
19:13gsneddersDomenic: they're more likely to land than the massive one jgraham submitted before
19:14gsneddersDomenic: at some point may as well close them for jgraham's original
19:14gsneddersDomenic: but I'll probably try and do something with them in a month or so
19:17jugglinmikejgraham: when you have a minute, could you confirm my interpretation here: https://github.com/w3c/wptserve/issues/116 ?
19:30jgrahamjugglinmike: So I don't know if it's that simple
19:30jgrahamThere are multiple things going on here
19:31jgrahamWe have multiple threads so multiple instances of each handler from that point of view
19:31jgrahamBut more importantly
19:31jgrahamAfter handling a response the handler can either close the connection or leave it open
19:32jgrahamIf close_connection=True on the response object no further requests should share the same response
19:33jgrahamAlso, in the case of your 204, you may need to ensure that content-length is set
19:33jgrahamIf that is set I would expect the browser to read the body even if HTTP says there ought not be one
19:36jgrahamjugglinmike: Heading home now, let me know if I'm talking ninsense
19:37jugglinmikejgraham: If we're talking about invalid responses, then it seems strange that it would need to be invalid "in the right way"
19:39jugglinmikeI saw that `close_connection` flag, but that seems to be logic layered on top of the base Python class
19:55jgrahamjugglinmike: Well the thing is this is pretty fundamental to the protocol, right
19:57jgrahamIf I send &quot;<some status line>\r\nContent-Length:0\r\n\r\nSome content&quot; then the client will read to the end of the headers, read 0 more bytes and assume that&#39;s the response.If it then reads again from the same connection it will see &quot;Some content&quot; before the start of the actual next response
19:58jgrahamSo you either need a coret content-length header or to ensure that the connection is closed
20:04jugglinmikebut when we&#39;re talking about a 204, the content-length is not required, and the client is correct to assume that there is no content
20:04jugglinmike(actually, I believe the content-length is forbidden in that case, but whatever)
20:05jugglinmikethe issue extends beyond 204/205 responses, though
20:05jugglinmikeThe demonstration I shared shows how it can effect 200&#39;s
22:03jgrahamjugglinmike: So I don&#39;t really know what behaviour you expect
22:05jgrahamYour testcase writes a response and lies about the content-length. The browser reads content-length bytes. The remaining bytes get buffered. Later, because we don&#39;t close the connection, the browser ends up reading the bytes that were written to the socket earlier
22:05jgrahamIf you don&#39;t want that you either need to not lie in content-length or to close the connection when the request is done
22:06jgrahamThat&#39;s just how keep-alive works afaict
22:07jgrahamWhat do you think wptserve ought to do in this case?
22:08jugglinmikeI had the same opinion about lying about content-length, but I thought that is what annevk was requesting in this comment https://github.com/w3c/web-platform-tests/pull/5037#issuecomment-285846291
22:17jgrahamjugglinmike: I assume &quot;with body&quot; there doesn&#39;t mean &quot;no content length&quot;, but maybe annevk should explain
22:17jgrahamBecause I might not understand him
22:21jugglinmikeHm, it might. I didn&#39;t consider this aspect of invalidity
22:22jugglinmikeThe thing that is still confusing me is the distinction between &quot;the connection&quot; (the thing that the browser closes) and &quot;the socket&quot; (the thing that wptserve shares between all requests)
22:23jugglinmikeIn the demo, browsers like Chrome and Firefox seem to &quot;close the connection&quot; for the first iframe, once they have read the specified number of bytes from the 200 response
22:24jugglinmike(I&#39;ve hidden the first iframe with CSS, but it correctly renders the initial document)
22:27jugglinmikeSo the second request seems like an independent &quot;connection&quot;, but because it has the same &quot;socket&quot; (or &quot;stream&quot; as it referred to in the Python docs), it receives the extra bytes
22:34jgrahamjugglinmike: The point of keep alive is that the TCP connection isn&#39;t closed. The right number of bytes are read and it&#39;s assumed that anything else on the wire is part of the next response
22:35jgrahamc.f. https://en.wikipedia.org/wiki/HTTP_persistent_connection and links therein
22:37jugglinmikeI think I&#39;m getting it now
22:38jugglinmikeThis is why calling `flush` after the extra content didn&#39;t work
22:39jugglinmikeI was thinking that the standard library was changing the `_wfile` stream&#39;s underlying socket for each request
22:39jugglinmikeIn that situation, the extra content from one request handler would be buffered until the switch happened, I think
22:40jugglinmikeAnd it could be resolved by explicitly flushing the buffer at the end of the handler
22:40jugglinmikebut that doesn&#39;t describe the reality, anyway
22:41jgrahamNo, it&#39;s the same socket
22:41jgrahamNot changing that is basically the optimisation
22:43jugglinmikeSure enough: specifying &quot;Connection: close&quot; avoids the problem
23:08jugglinmikejgraham: I&#39;ll follow up with that wptserve issue and the `eventsource` patch tomorrow. Thanks for your help and your patience, as always
15 Mar 2017
No messages
Last message: 11 days and 22 hours ago