| 09:25 | <annevk> | benjamingr__: are you around? Do you want your name in the Acknowledgments section? |
| 11:29 | <jgraham> | annevk: What's the COOP scenario, exactly? (my initial reaction is "you get a contextDestroyed event for the old context and a contextCreated event for the new one, even if they're the same 'tab' from the point of view of the user") |
| 11:30 | <annevk> | jgraham: that is correct; I guess I'm mainly wondering if you know they relate to the same tab |
| 11:31 | <annevk> | jgraham: HTML still needs to describe something called browsing session, which will provide some coherence for this |
| 11:31 | <annevk> | (a browsing session is a tab, I guess) |
| 11:32 | <jgraham> | Yeah, I guess that's an interesting point. For WebDriver/HTTP we have window handles that are supposed to be for the user-percieved windows |
| 11:32 | <jgraham> | And these things are supposed to be compatible |
| 11:33 | <annevk> | jgraham: and we might not discard in the future, but freeze the browsing context somehow so you can do fastback |
| 11:35 | <jgraham> | Yeah, I assume that navigation can not discard nested contexts even in the no-COOP case, and it's not super clear if users will be confused by not getting events in that case |
| 11:39 | <andreubotella> | I was under the impression that a top-level browsing context was a tab |
| 11:40 | <annevk> | andreubotella: that was the case until we changed that with COOP |
| 11:40 | <annevk> | andreubotella: now it's N:1 |
| 11:41 | <andreubotella> | I see |
| 11:49 | <andreubotella> | annevk: btw, playing around with file inputs and urlencoded I found more newline normalization bugs |
| 11:50 | <annevk> | Cool, did you file bugs? |
| 11:51 | <andreubotella> | it's actually something all browsers share, even if imo it should count as a bug in the browsers, so I was gonna file a bug on the url standard when I had the tests on wpt |
| 11:52 | <andreubotella> | but I got slightly tripped by the fact that webkit somehow doesn't percent-encode \x00 on urlencode over POST, leading to the same nonsense with the page being detected as a download |
| 11:52 | <andreubotella> | I'll file a bug for that one |
| 12:08 | <annevk> | That sounds like a fun, thanks for testing 🙂 |
| 12:23 | <annevk> | andreubotella: that fileInput creation technique (with Object.assign) is rather clever |
| 12:24 | <andreubotella> | I saw bsittler use it in the original multipart/form-data PR that got closed downstream |
| 12:25 | <annevk> | Heh, must have missed that cause I don't remember seeing this before |
| 12:28 | <annevk> | andreubotella: let me know if you want it to be boilerplate-free and I'll wait a bit with merging |
| 12:28 | <andreubotella> | sure, I'll make it window.js |
| 12:44 | <annevk> | andreubotella: so I realized something since you filed that issue |
| 12:44 | <annevk> | andreubotella: this is testing form submission, and that is doing the newline normalization, and only after that is it testing urlencoding |
| 12:45 | <andreubotella> | annevk: in multipart/form-data, newlines in filenames aren't touched |
| 12:45 | <annevk> | andreubotella: I see that you are suggesting that newline normalization should only happen for urlencoding and not multipart, but I'm not sure if that's correct as it also happens when creating a FormData from a <form> (or perhaps only in Chrome) |
| 12:47 | <annevk> | I guess I should look up when we defined "append an entry" as I'm pretty sure we considered at least some of this |
| 12:49 | <andreubotella> | when I tested the newline normalization when creating a FormData from a form, I forgot to test filenames |
| 12:50 | <andreubotella> | I'll open a wpt PR for that later today |
| 12:51 | <annevk> | https://github.com/whatwg/html/commit/a1e8b1a9725dc716326f564b91a29aca19daf2f2 does seem to preserve intent in that it only happens for value if it's not a File, but maybe it could be read some other way that name should also not be affected? |
| 12:51 | annevk | will go further back in blame |
| 12:55 | <annevk> | I found something |
| 12:55 | <annevk> | https://github.com/whatwg/html/commit/d9fa54d643a7cd041ce31766f1ba5848cd76d18f |
| 12:55 | <annevk> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=17460 |
| 12:55 | <annevk> | zcorpan_ is to blame |
| 12:56 | <zcorpan_> | wat |
| 12:56 | <andreubotella> | I'll look at it later, g2g |
| 12:56 | <annevk> | And as was tradition back then there are no tests, links to implementation bugs, or anything 🙂 |
| 13:01 | <zcorpan_> | ah I remember that issue. I was going to say it predated testharness.js, but that wasn't the case. https://github.com/w3c/testharness.js/commit/1780607fc4582b65b7fcdded3e39e79e95c8d915 |
| 13:04 | <zcorpan_> | Has anyone written about the history of web-platform-tests? |
| 13:04 | <annevk> | I don't think jgraham has a blog or it must be very well hidden |
| 13:30 | <jgraham> | If I do I also hid it from myself |
| 13:53 | <jkt_> | :') |
| 14:02 | <andreubotella> | so apparently filenames just fell through the cracks? |
| 14:02 | <zcorpan_> | andreubotella: yeah |
| 14:03 | <zcorpan_> | I'd guess there are a lot of old spec changes like this |
| 15:30 | <smaug____> | Now it escapes my mind... what is the name for the proposal to add some new/better widgets/controls to the web |
| 15:32 | <zcorpan_> | smaug____: open ui |
| 15:33 | <smaug____> | thanks |
| 15:43 | <MikeSmith> | https://lists.w3.org/Archives/Public/public-html/2007Apr/0564.html from Maciej is arguably where the history of web-platform-tests started (to trace it all the way back) |
| 15:44 | <MikeSmith> | or from the same thread, https://lists.w3.org/Archives/Public/public-html/2007Apr/0532.html from DanC |
| 15:46 | <jgraham> | Well like with all history there are a number of different threads you can pull to unravel different parts of the story |
| 15:46 | annevk | finds https://lists.w3.org/Archives/Public/public-test-infra/2013JanMar/0052.html |
| 15:47 | <annevk> | I'm curious about the Opera side of the story |
| 15:48 | <jgraham> | Right, I think there's an intesting part that happened before I was involved where Opera ended up having a QA department with Hixie writing tests for web standards |
| 15:48 | <MikeSmith> | https://krijnhoetmer.nl/irc-logs/html-wg/20090127 |
| 15:48 | <MikeSmith> | https://wiki.whatwg.org/index.php?title=Testsuite |
| 15:48 | <MikeSmith> | https://lists.w3.org/Archives/Public/public-html/2009Jan/0471.html |
| 15:49 | <jgraham> | And the way that interacted with the Acid tests for CSS |
| 15:49 | <annevk> | jgraham: I think Hixie was the department (at least the automated part of it) and he got Kam hired to replace him at some point |
| 15:50 | <annevk> | But yeah, that's 2003-2005 or so |
| 15:55 | <jgraham> | Good thing we fixed all the problems we discussed in 2009 about how to get tests reviewed and how to link tests to the spec in a reliable way. |
| 15:55 | <jgraham> | Otherwise it might look like we hadn't achieved much in the last decade or so :p |
| 15:58 | <jgraham> | On the other hand I guess these days we don't bother with an email every time a browser vendor contributes 43 tests. |
| 16:17 | <gsnedders> | jgraham: also where Hixie wrote tests while a student ;P |
| 16:18 | <gsnedders> | MikeSmith: I forget the exact year when it was decided that CSS 3 should pretty much all be automated tests |
| 16:19 | <gsnedders> | annevk, jgraham: Hixie was an instrumental part of getting the tooling to run automated tests working within Opera, and it was that role which Kam was hired to take over, allowing Hixie to focus on the actual testing side of things |
| 16:21 | <MikeSmith> | gsnedders: was before 2007 maybe? |
| 16:22 | <MikeSmith> | at least I think the CSS test suite work started quite early |
| 16:23 | <MikeSmith> | Tantek would remember I guess |
| 16:36 | <MikeSmith> | annevk: in the general case where some server-side application code for CORS handling throws for some reason, can you think of an HTTP status code that can be used to convey it? |
| 16:36 | <MikeSmith> | context is https://stackoverflow.com/questions/42755131/enabling-cors-in-cloud-functions-for-firebase/65127649#65127649 |
| 16:37 | <MikeSmith> | ... where the person has the applicaion code intentionally written to send a 500 response |
| 16:37 | <annevk> | MikeSmith: 403 per https://fetch.spec.whatwg.org/#http-responses |
| 16:37 | MikeSmith | looks |
| 16:37 | <annevk> | (last paragraph) |
| 16:38 | <MikeSmith> | ok yeah but that says “In case a server does not wish to participate in the CORS protocol” |
| 16:38 | <MikeSmith> | which makes sense |
| 16:40 | <MikeSmith> | but I often see people having application code written to send 500 responses in code that’s intended to participate in the CORS protocol but that throws due to some unexpected thing |
| 16:40 | <MikeSmith> | to me, in general, it seems not optimal to send a 500 from application code — because that’s gonna make it harder for you to distinguish cases of your application code throwing an intended error from cases of the server/runtime code hitting some other kind of internal failure (maybe even before it ever executes your application code) |
| 16:42 | <MikeSmith> | (but maybe that’s just me, and sending a 500 in such cases is actually a normal best practice) |
| 16:42 | <annevk> | MikeSmith: we could clarify that line I suppose as it's a little vague |
| 16:42 | <MikeSmith> | OK |
| 16:42 | <annevk> | MikeSmith: what it really means is that if the server doesn't want to allow the particular request (or participate in the CORS protocol at all), do this |
| 16:43 | <annevk> | but it's still a suggestion since servers can do whatever |
| 16:43 | <MikeSmith> | sure |
| 16:49 | <Domenic> | MikeSmith: 500 makes sense for me in cases like that. E.g. in all my Node servers, if an exception gets thrown while processing a request/preparing to create a response, we turn it into a 500 response. That code snippet just looks like someone manually doing the try/catch, instead of letting it bubble to their server-level error handler, which is somewhat understandable since I'm not sure how well generic server |
| 16:49 | <Domenic> | request/response handling deals with preflight-type things. |
| 16:50 | <Domenic> | (But, the OP's code for that question makes no sense, where they're always sending a 500.) |
| 16:57 | <MikeSmith> | Domenic: ah yeah, good point about this case — about just letting the exception bubble rather than catching it |
| 16:59 | <MikeSmith> | but otherwise yeah I guess if there’s nothing more specific that the application code can determine, then 500 works |
| 17:30 | <gsnedders> | MikeSmith: pre-CSS3 it was all manual stuff though, that's the thing |
| 17:30 | <gsnedders> | well "manual", it was all screenshot based |
| 17:37 | <gsnedders> | MikeSmith: https://www.w3.org/blog/CSS/2009/06/23/resolutions_69/ seems like it was only June 2009 that reftests were officially adopted for CSS |
| 17:53 | <andreubotella> | is there an issue open anywhere for wpt.fyi trying to link to the nonexistent html source in github rather than to an .any.js? |
| 17:55 | <andreubotella> | nevermind, found it |
| 17:55 | <andreubotella> | https://github.com/web-platform-tests/wpt.fyi/issues/1476 |
| 20:04 | <andreubotella> | annevk: I misinterpreted your earlier comment about FormData in Chrome |
| 20:05 | <andreubotella> | I wrote down the whole story about why this is a urlencoded-only thing in https://github.com/whatwg/url/issues/562#issuecomment-738276174 |