| 04:37 | <annevk> | Well, agent cluster, no? |
| 04:38 | <annevk> | Ideally |
| 04:43 | <MikeSmith> | annevk: does the term "deque" not describe this? |
| 05:01 | <annevk> | MikeSmith: it does I think, but the prepending isn’t an important feature and could be factored out |
| 05:09 | <MikeSmith> | ah OK |
| 07:45 | <annevk> | MikeSmith: would it make sense to change x-ua-compatible to be non-conforming? |
| 09:28 | <ondras> | so, I have a web with origin X; I open a new window with a URL from the same origin (via window.open), and yet I receive |
| 09:28 | <ondras> | Permission denied to access property "href" on cross-origin object |
| 09:28 | <ondras> | when I try to access win.location.href |
| 09:29 | <ondras> | what kind of black magic is that? |
| 09:33 | <ondras> | the popup window's content-type of application/json seems to be a problem |
| 09:33 | <ondras> | is that a standardized behavior? or a browser bug? |
| 09:35 | <annevk> | ondras: it's probably not as well-defined as it should be, but that's what I would expect for that case |
| 09:35 | <annevk> | ondras: actually, I think what would be ideal is that you see a closed popup that's still at initial about:blank and the browser swapped the browsing context so the user gets to see the JSON still |
| 09:37 | <ondras> | annevk: is there a reason for that? why should I *not* access the popup's location in this case? |
| 09:38 | <ondras> | it fails even if the popup has the access-control-allow-origin:* (not sure why this should be required tho) |
| 09:38 | <annevk> | ondras: because we only create documents for certain MIME types and we shouldn't expose documents for browser internal viewers |
| 09:39 | <ondras> | annevk: I see. I do not want to access the document, though - I am only interested in the location (oauth popup with secret code in the url) |
| 09:39 | <annevk> | Then use fetch() or some such |
| 09:40 | <ondras> | that is not really suitable for oauth. the user needs a real new window to perform the authorization |
| 09:41 | <ondras> | (and ends up being redirected to my problematic redirect_uri that happens to contain JSON) |
| 09:41 | <ondras> | okay, so I conclude that this is currently not possible. thanks for explanation! (still not sure why accessing the same-origin location for a json document shall be forbidden though) |
| 09:46 | <annevk> | Well, poking a hole like that requires a bunch of special cases that don't seem worth it |
| 09:46 | <annevk> | Just serve HTML |
| 09:47 | <ondras> | done. switched the content based on the Accept: header. |
| 11:01 | <MikeSmith> | annevk: yes, I think it would make sense to change x-ua-compatible to be non-conforming |
| 11:34 | <annevk> | JakeA: could you move https://github.com/whatwg/fetch/issues/538#issuecomment-659350493 into its own issue pretty please? |
| 13:53 | <Domenic> | annevk: any chance you could look at https://github.com/whatwg/html/pull/5736 soon? |
| 13:58 | <andreubotella> | annevk: I was refactoring things and I just noticed that the TextEncoderStream algorithms used a stream of code units, not scalar values, for the cases when the split happened in the middle of a surrogate pair |
| 13:58 | <andreubotella> | and I completely missed this back at https://github.com/whatwg/encoding/pull/196 |
| 13:58 | <andreubotella> | whoops |
| 14:25 | <smaug____> | annevk: do you recall some helper site to check what all data browser ends up sending to the server when submitting a form? |
| 14:40 | <annevk> | smaug____: I use http://software.hixie.ch/utilities/cgi/test-tools/echo at times |
| 16:41 | <devsnek> | where is the best place to talk about css stuff |
| 16:41 | <Domenic> | devsnek: https://github.com/w3c/csswg-drafts/issues |
| 16:41 | <devsnek> | thanks |
| 16:50 | <annevk> | Anyone interested in doing some editorial review on XMLHttpRequest? It's a big change, but it does now use all IDL's latest goodies: https://github.com/whatwg/xhr/pull/285 |