| 00:28 | <MikeSmith> | muteki: without CORS, no site can make any cross-origin XHR/Fetch request from JavaScript to another site, period |
| 00:29 | <MikeSmith> | browsers by default block all scripted cross-origin requests |
| 00:30 | <MikeSmith> | CORS allows sites to opt-in to telling browsers that they are OK with receiving cross-origin requests |
| 00:30 | <MikeSmith> | actually “browsers by default block all scripted cross-origin requests” is not quite correct |
| 00:31 | <MikeSmith> | more accurately, browsers block frontend JavaScript code from accessing the response to any cross-origin request |
| 00:33 | <MikeSmith> | so you can make a cross-origin GET request to another site, but unless the site sends back teh Access-Control-Allow-Origin response header, your browser blocks your JavaScript code from accessing the response |
| 00:44 | <muteki> | MikeSmith: my bad, I was reading annevk's blog so what I meant is really without SOP, then CORS comes in and with CORS... |
| 00:45 | <MikeSmith> | yeah |
| 00:46 | <MikeSmith> | muteki: you might find https://w3c.github.io/webappsec-cors-for-developers/ worth reading |
| 00:46 | <muteki> | MikeSmith: yeah, I think your differentiation of allowing javascript to process the code v.s. issuing request+getting response are two separate things that I was confused initially |
| 00:47 | <MikeSmith> | yeah that is non-intuitive really |
| 00:47 | <MikeSmith> | I mean, by default you can even successfully make POST requests cross-origin |
| 00:48 | <muteki> | yeah, there is nothing really to protect that unless one leverages the preflight requirement |
| 00:48 | <MikeSmith> | right, as long as your request doesn’t add any headers or set to the Content-Type header to application/json or something, then any POST request will succeed cross-origin |
| 00:49 | <MikeSmith> | anyway I guess the https://w3c.github.io/webappsec-cors-for-developers/#csrf section in particular is where the problem case is explained |
| 00:49 | <muteki> | ok, thanks, let me read about it |
| 00:51 | <MikeSmith> | the last paragraph of https://stackoverflow.com/questions/34650915/it-seems-the-pre-flight-for-cors-doesnt-make-sense-is-it-a-joke/34668785#34668785 from Domenic is also a very good succinct explanation |
| 00:52 | <MikeSmith> | and https://stackoverflow.com/questions/9222822/why-do-browser-apis-restrict-cross-domain-requests/9223680#9223680 is very good too |
| 00:59 | <muteki> | thanks so much, I think I have a better idea what CORS really provide and the rationale behind using it |
| 01:10 | <muteki> | I that last link also implies why normal cross-origin img request via <img> tag is ok but canvas img loading is not ok.... (have been wondering that for a while) (because canvas can read back the img and potentially send it back to the bad site) |
| 01:15 | <muteki> | correction: canvas image loading is ok, but once tainted, can't pull data out |
| 01:56 | <MikeSmith> | Domenic: about the checker problem that broke the HTML spec build, in https://github.com/w3c/web-platform-tests/commit/bf24230 I added a test to make sure it doesn’t regress |
| 07:25 | <MikeSmith> | annevk: any clue about https://stackoverflow.com/questions/47158940/include-authorization-header-using-fetch-api-post-method |
| 09:14 | <kochi> | Hmm, Ryosuke suggested somewhere else than Toronto, any idea if we do elsewhere? |
| 09:23 | <smaug____> | kochi: where was that discussed? |
| 09:23 | <kochi> | smaug____: https://github.com/w3c/webcomponents/issues/713 |
| 09:24 | <smaug____> | hmm, I'm so not getting emails about that issue |
| 09:24 | <smaug____> | even though I'm subscribed :/ |
| 09:24 | <kochi> | smaug____: I thought you preferred somewhere in Europe |
| 09:24 | <smaug____> | oh, now I got it |
| 09:25 | <kochi> | strange, I explicitly mentioned @smaug---- in my comment. |
| 09:28 | <smaug____> | (there are direct flights from Helsinki to Tokyo, so it wouldn't be too hard for me) |
| 09:31 | <smaug____> | Though, Google does have offices in London. Any blink folks there? |
| 09:31 | <Ms2ger> | I think so |
| 09:33 | <smaug____> | -> out |
| 09:37 | <kochi> | yes, Google has London office, and has Chrome people there. |
| 09:37 | <kochi> | London wouldn't be hard for me. |
| 09:37 | <kochi> | But I've never been there ;) |
| 09:43 | <JakeA> | smaug____: beverloo and I work at Google in London |
| 09:44 | <JakeA> | (although I don't work on blink) |
| 09:45 | <kochi> | So now Berlin (Mozilla), London (Google), Tokyo (Google), Toronto (Mozilla) are the options. |
| 09:46 | <kochi> | How the weather in Berlin in February/March? |
| 09:47 | <JakeA> | Dan Abramov of React is in London too |
| 09:51 | <kochi> | Is London not as bad as Toronto in Feb/Mar? |
| 09:55 | <JakeA> | Winters in southern UK aren't particularly serious. We very rarely get snow. |
| 10:02 | <kochi> | Then it's like Tokyo, or better maybe. We have snow once or twice a year. |
| 11:58 | <gsnedders> | is there any way to make Fetch compress the request body? |
| 12:39 | <zcorpan> | rbyers: any update on https://bugs.webkit.org/show_bug.cgi?id=5991#c17 ? :-) |
| 12:39 | smaug____ | doesn't understand what is wrong with snow ;) |
| 12:39 | <jgraham> | Not very relevant but you could also use the Mozilla London office for a SW meeting if you wanted. |
| 12:39 | <nox> | There is Paris too. :P |
| 12:39 | <smaug____> | jgraham: this is webcomponents, and thought there might be a bit too many people possibly coming |
| 12:42 | <jgraham> | smaug____: Ah. Well yeah I guess more than ~20 would be hard |
| 12:43 | <smaug____> | Maybe there won't be too many, but it is unclear still |
| 12:43 | <jgraham> | Google is probably a better bet in London, just making sure you have options :) |
| 12:44 | <smaug____> | Does Google still have the office on the Buckingham Palace's backyard? |
| 12:45 | <smaug____> | looks like so |
| 12:51 | <foolip> | annevk: is html5.org yours? is it really based on https://github.com/whatwg/misc-server/tree/master/html5.org? |
| 12:52 | <annevk> | foolip: it's not automatically deployed, but I try to keep those directories synchronized |
| 12:52 | <foolip> | annevk: OK, was thinking about deleting that, but I won't then |
| 12:53 | <foolip> | (In the context of maybe merging misc-server into whatwg.org/config/ |
| 12:53 | <foolip> | They're kind of interdependent now... |
| 12:53 | <annevk> | You could just leave this in misc-server for now I suppose |
| 12:54 | <foolip> | Just html5.org? That'd work, yeah. |
| 12:54 | <annevk> | I'm also happy to move it elsewhere, but not this week |
| 12:54 | <foolip> | Nope, doesn't really matter. |
| 16:06 | <JakeA> | wanderview: When did e10s become the default in Firefox? |
| 16:06 | <wanderview> | JakeA: single content process or multiple content processes? |
| 16:07 | <wanderview> | JakeA: its actually a hard question to answer because it was a gradual rollout with all kinds of exceptions |
| 16:07 | <wanderview> | JakeA: 57 may be the real first release where 100% users have e10s on desktop because legacy addons blocked e10s for many users |
| 16:07 | <JakeA> | wanderview: I guess I'm asking, when did JS in one tab stop blocking JS in an unrelated tab? |
| 16:08 | <wanderview> | JakeA: we enabled 4 content processes in FF54, but many users may not have seen that because of addons, etc: https://medium.com/mozilla-tech/the-search-for-the-goldilocks-browser-and-why-firefox-may-be-just-right-for-you-1f520506aa35 |
| 16:09 | <wanderview> | JakeA: pages that get put in the same process can still block each other |
| 16:09 | <JakeA> | wanderview: gotcha, cheers! |
| 16:10 | <wanderview> | JakeA: we have "quantum DOM" plans to fix that within a process, but its not ready yet |
| 16:11 | <JakeA> | wanderview: so does Firefox now create a new process per event loop? |
| 16:12 | <wanderview> | JakeA: no... we create up to four processes and assign tabs to them somewhat randomly |
| 16:12 | <JakeA> | wanderview: ahh ok, gotcha, thanks! |
| 16:18 | <wanderview> | JakeA: not sure if it matters or not, but we have a thing in "Menu->Options search for perf" that lets you choose up to 7 processes or as few as 2 processes |
| 16:18 | <wanderview> | oh, it goes down to1 now |
| 18:12 | <Domenic> | foolip: several times over the last couple of days I've browsed through wpt.fyi and found failing-in-all-four-browsers tests that seem pretty clearly incorrect. I guess I'll file bugs, but are you perhaps working on a larger project to canvas those? |
| 18:14 | <foolip> | Domenic: we're not planning a repo-wide effort like that, but it is the obvious place to start if trying to improve the test suite itself as opposed to implementations |
| 18:14 | <Domenic> | Hmm OK |
| 18:16 | <foolip> | Domenic: as a start, https://metrics5-dot-wptdashboard.appspot.com/metrics/ will make it easy to find them |
| 18:16 | <Domenic> | Ah nice |
| 18:17 | <foolip> | That'll become the default view (after some polish) |
| 18:23 | <Domenic> | Hmm I guess the reliability of the data really hurts this |
| 18:23 | <Domenic> | E.g. Firefox randomly missing results |
| 18:24 | <Domenic> | Or maybe it's just too beta |
| 18:24 | <Domenic> | E.g. https://metrics5-dot-wptdashboard.appspot.com/metrics/dom/nodes/prepend-on-Document.html says there are 7 tests one of which passes nowhere, but there are 5 tests and they all pass in at least Firefox. |
| 22:51 | <foolip> | Domenic: run cadance and completeness of results is a P1 for us, it'll get good. |
| 22:51 | <foolip> | Domenic: oh, but that might be a bug |
| 23:58 | <foolip> | Domenic: I told mditty (hi!) and there are actually 7 rows there |
| 23:59 | <mditty> | Domenic: The metrics view is showing all 7 rows listed at https://metrics5-dot-wptdashboard.appspot.com/dom/nodes/prepend-on-Document.html |
| 23:59 | <foolip> | Confusing bit is that testharness.js tests all get an extra line for the harness status, and that not the same commit of wpt was run on all browsers, so the last line is Edge only |
| 23:59 | <mditty> | It looks like Edge is the only one with a subtest named "DocumentType.prepend" |