| 01:49 | <Domenic> | Basically the manifest spec screwed us by setting that precedent so now we follow it |
| 01:53 | <Domenic> | Also, why is the stylesheet still not fixed for tables -__ |
| 01:53 | <Domenic> | -__-, even |
| 04:43 | <annevk> | Can't we follow CSP report precedent instead? If that is different? |
| 06:00 | <Domenic> | https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP#Sample_violation_report |
| 06:00 | <Domenic> | ... huh, so it's dash-delimited. That seems... worse. |
| 06:01 | <Domenic> | also still map CSP uses "uri" |
| 06:01 | <Domenic> | *mad |
| 08:47 | <annevk> | Yeah, I complained about that bit already, might be "fixed" by a newer version |
| 10:48 | <smaug> | annevk: this agent thing. What defines the concept which BroadcastChannel uses? |
| 10:50 | <annevk> | smaug: they are origin-bound, no? Kind of cross-cutting with agents |
| 10:50 | <smaug> | ok, perhaps I don't understand what an agent is |
| 10:51 | <smaug> | or not perhaps, I just don't :) |
| 10:52 | <annevk> | smaug: a dedicated worker is an agent, or a set of windows that are similar-origin and can access each other |
| 10:52 | <smaug> | ok, so that window part is like, hmm, DocGroup in Gecko |
| 10:53 | <smaug> | is there anything for non-similar-origin? |
| 10:53 | <annevk> | smaug: no, we should prolly have terms for that too at some point |
| 10:53 | <smaug> | (that would be TabGroup in Gecko) |
| 11:02 | <smaug> | and the agent for BroadcastChannel isn't needed because something. ShareArrayBuffer just isn't supported by its postMessage |
| 11:03 | <smaug> | Should one be able to pass SharedArrayBuffer cross origin? |
| 11:03 | <smaug> | using window.postMessage |
| 11:04 | <smaug> | I would expect so, if window.postMessage supports it in same-origin case |
| 12:18 | <annevk> | smaug: no, that will fail |
| 12:19 | <smaug> | same-origin case? |
| 12:49 | <annevk> | No cross fails |
| 13:40 | <Domenic> | you can pass cross-origin if the origins could become same-origin-domain via document.domain |
| 13:40 | <Domenic> | i.e. you can pass from a.example.com to b.example.com |
| 13:41 | <Domenic> | maybe we should add that to the list of examples |
| 14:01 | <annevk> | We should also add a note that same-origim can be different agents |
| 14:02 | <annevk> | Eg two independently opened same-origin browsing contexts |
| 14:33 | <knunger004> | hi, i'm totally out of choice now. This is about XMLHttpRequest(...) , https://paste.ubuntu.com/24387209/ |
| 14:33 | <knunger004> | the issue i'm facing is regarding 307 url redirection by the proxy server at localhost:8080, when some resource isn't found. |
| 14:33 | <knunger004> | locally. |
| 14:34 | <knunger004> | i get the following error , "Uncaught NetworkError: Failed to execute 'send' on 'XMLHttpRequest': Failed to load 'http://localhost:7860/data.json'; |
| 14:35 | <knunger004> | However, when the resource is found locally, it works perfectly fine. |
| 14:36 | <knunger004> | https://paste.ubuntu.com/24387231/ this is the code that prepare a custom redirect response header. |
| 14:51 | <annevk> | knunger004: that is not really sufficient information to know where it goes wrong |
| 14:52 | <annevk> | knunger004: also, stackoverflow is prolly a better place |
| 15:06 | <knunger004> | annevk, alright |
| 17:29 | <Domenic> | annevk: oooh, interesting, i didn't realize URSOBC excluded such cases |
| 17:30 | <Domenic> | That might be a reason it's based on browsing contexts instead of realms |
| 17:46 | <annevk> | But the whole browsing context angle makes no sense given navigation |
| 17:47 | <annevk> | Or I guess you can see it as some kind of snapshot, but still, we can do better eventually |
| 18:01 | <Domenic> | I mean, it makes sense if you think of it as a definition, instead of a set that gets statically added to and removed from |
| 18:01 | <Domenic> | getCurrentURSOBCs() instead of const ursobcs = [] |
| 18:01 | <Domenic> | It's a bit confusing conceptually, but I think it all *works* |
| 18:04 | <annevk> | We add state to it though |
| 18:06 | <annevk> | We should move that state to the corresponding agent over time and then figure out when it gets created; that will make it all go away |
| 18:07 | <Domenic> | ah, yeah, we did |
| 18:07 | <Domenic> | now i'm wondering if the custom elements reaction stack should be event-loop bound instead of URSOBC-bound |
| 18:09 | <annevk> | It should be similar-origin window agent bound |
| 18:10 | <annevk> | And some stuff in DOM should be too, I should export these agents |
| 18:11 | <Domenic> | it seems more like a task queue-ish thing which makes me think event loop |
| 18:11 | <Domenic> | i guess in implementations it's not going to be shared across processes? |
| 18:12 | <Domenic> | But neither are event loops, in practice, I think |
| 18:12 | <annevk> | Event loops cannot be shared across processes |
| 18:12 | <Domenic> | I thought per spec you could have one event loop for all browsing contexts... |
| 18:13 | <Domenic> | yeah, there is at most one event loop per URSOBC, but not at least one (like I thought there was until recently) |
| 18:13 | <annevk> | Sure, in a single-process impl |
| 18:13 | <Domenic> | right ok so the mapping i have wrong is agent <-> process. it's agent <-> theoretically-possible process. |
| 18:13 | <annevk> | Domenic: we don't want to export subcluster right? |
| 18:14 | <Domenic> | Agreed |
| 18:14 | <annevk> | Domenic: agent's realm and agent's global object? |
| 18:14 | <Domenic> | annevk: I'd lean toward not exporting them for now, but maybe that's over-conservative. |
| 18:15 | <annevk> | seems fine to me, especially since they don't work across all agents |
| 18:15 | <Domenic> | Yeah that's what's worrying |
| 18:15 | <Domenic> | Maybe they should be renamed "worker agent's realm" etc. Or... "workerish" so worklets are included? I dunno. |
| 18:15 | <Domenic> | "single-global agent's global object" is not short enough IMO |
| 18:16 | <annevk> | I think it's fine and we should worry about when either someone needs to use them elsewhere or someone gets confused |
| 18:17 | <Domenic> | SGTM |
| 18:30 | <annevk> | Domenic: with respect to event loop, I'd like that to just become a queue or some such on each agent |
| 18:31 | <Domenic> | sure, 1:1 event loop <-> agent would work well for me |
| 18:31 | <annevk> | Domenic: and then we'd allow UAs to merge queues of window agents or some such (no need to require those to be concurrent and not observable either) |
| 18:32 | <annevk> | Domenic: which brings us back to the status quo, except the formal model is more sensible (and better grounded as event loops are currently located nowhere...) |
| 18:43 | <annevk> | Domenic: other question, some of your JS PRs to remove willful violations gained consensus it seems |
| 18:43 | <annevk> | Domenic: did you lose track or just waiting for something? |
| 18:45 | <Domenic> | annevk: just hasn't gotten to the top of the priority queue unfortunately |
| 18:45 | <Domenic> | oh, PRs? |
| 18:45 | <Domenic> | I think none of my actual PRs have consensus |
| 18:46 | <Domenic> | Unless I lost track |
| 18:46 | <annevk> | Domenic: https://github.com/tc39/ecma262/pull/688, but it needs modifications |
| 18:46 | <Domenic> | Ah right yeah |
| 18:47 | <Domenic> | Yeah doing that work is in a pile with a few others that got consensus |
| 18:47 | <Domenic> | bterlson was supposed to do HTMLAllCollection to show me how he envisions HTML integration working per the consensus |
| 18:47 | <Domenic> | But he never did, so I should probably do the work myself |
| 18:47 | <annevk> | Ah okay, I'd just wait a bit on bterlson then |
| 18:48 | <Domenic> | Nah it's been like 7 months, I gotta do it myself |
| 18:48 | <Domenic> | https://dl.dropboxusercontent.com/u/20140634/agents/multipage/webappapis.html#integration-with-the-javascript-agent-formalism is updated |
| 18:48 | <Domenic> | annevk: should we specify worklet [[CanBlock]] in this PR? |
| 18:49 | <annevk> | Domenic: I decided yes, based on flagxor's feedback and nobody objecting |
| 18:49 | <Domenic> | CanBlock yes, or yes we should? It seems like it's not in the current PR |
| 18:49 | <annevk> | Domenic: but easily changed if we get some feedback |
| 18:49 | <Domenic> | annevk: oh nevermind |
| 18:49 | <Domenic> | was looking in the wrong place |
| 18:49 | <annevk> | kk |
| 18:51 | <annevk> | Domenic: seems we already had the same-origin domain iframe example too in your list of examples at the bottom of the PR btw, forgot to reply to that earlier |
| 18:51 | <Domenic> | Hmm yeah I guess I did say "could be" and "cannot be" |
| 18:52 | <Domenic> | Did you want to add the "two independently opened windows" example? |
| 18:52 | <annevk> | Domenic: I think the note I added is good enough |
| 18:52 | <Domenic> | Oh I see |
| 18:53 | <annevk> | It seems better there, since it might directly conflict with what folks think when they see "similar-origin" |
| 18:53 | <annevk> | I couldn't think of a better term though |
| 18:54 | <annevk> | The whole confusion with lth came from Gecko calling this a "DocGroup" |
| 18:54 | <annevk> | I think |
| 18:56 | <annevk> | Domenic: is Vat > Agent Cluster still true? I guess a Vat is the browser? |
| 18:56 | <Domenic> | I think vat is supposed to be agent |
| 18:57 | <annevk> | Domenic: hmm no, I guess Vat is Agent Cluster or Agent, okay |
| 18:58 | <annevk> | I was trying to figure out if there could be something between User agent and Agent Cluster, but that doesn't really seem possible due to BroadcastChannel and storage events |
| 19:05 | <Domenic> | Hmm I don't follow the connection, but I do think there's probably not anything between them |
| 19:23 | <annevk> | I was imagining that something stronger than an Agent Cluster would not be able to use postMessage() between themselves |
| 19:25 | <annevk> | If we call that kind of thing a Super Agent, then the problem is that as soon as you have two Super Agents, and then one of them creates a Window that has the same origin as a Window of the other, you're in trouble, as those need to be able to message each other |
| 19:25 | <annevk> | Through BroadcastChannel and storage events |
| 19:26 | <annevk> | Oh, and shared workers of course. |
| 19:27 | <annevk> | And service workers. |
| 19:27 | <annevk> | So many holes. |
| 19:43 | <Domenic> | I think if we wanted to restrict sharing SABs to same-origin-domain, not just similar-origin, we would do that in the definition of agent clusters. I prefer being more permissive though. |
| 20:10 | <Domenic> | I guess an argument for more restrictive is that it helps us avoid propagating document.domain in the hope that maybe one day we could remove it or limit it to some mode |