| 09:22 | <Noam Rosenthal> | annevk: for the fetch issue, can we count on client to always be task destination? useParallelQueue seems to change that, e.g. for sync XHR but I guess it's not in use much? |
| 09:23 | <Noam Rosenthal> | I guess it's OK in that case to use the parallel queue as the task destination anyway (thinking out loud) |
| 09:37 | <annevk> | Noam Rosenthal: I'm not sure, I suspect that in general we have to do more of that and less useParallelQueue |
| 09:37 | <annevk> | Noam Rosenthal: the effect could be that if you have to use a parallel queue you don't get automatic timing reporting? |
| 09:38 | <annevk> | I suspect you're more familiar with callers at this point, I haven't reviewed those in quite a while |
| 09:39 | <Noam Rosenthal> | annevk: only sync-xhr uses parallel queue from what I could gather. Also there are barely any callers of processResponseEndOfBody once we do the automatic reporting. From what I see it's OK to use the regular task destination and perform both operations |
| 09:39 | <annevk> | That would be great |
| 09:40 | <annevk> | I'll make sure to take another look later today |
| 09:40 | <Noam Rosenthal> | I'll make sure to take another look later today |
| 11:02 | <smaug> | Does anyone know folks from Github? |
| 11:03 | <smaug> | It seems to be relying on very specific bfcache behavior https://bugzilla.mozilla.org/show_bug.cgi?id=1772739#c10 |
| 11:35 | <annevk> | Luca Casonato: I saw you agreed to forbidding H/1 connections for upload streams, are you going to look at the full duplex issue still? I think we should solve that, although I suppose I could merge this PR and we'd leave the "blocking" label there for now; Yutaka Hirano thoughts? |
| 12:35 | <Luca Casonato> | annevk: yeah that sounds good. I am at https://webengineshackfest.org/2022/ until tomorrow, and then at another conf on Thursday, so I won’t get to the full duplex streaming until Friday |
| 12:57 | <annevk> | Ooh cool, still hope to be able to visit that one year; enjoy! |
| 13:43 | <Domenic> | It seems to be relying on very specific bfcache behavior https://bugzilla.mozilla.org/show_bug.cgi?id=1772739#c10 |
| 15:29 | <Luca Casonato> | Ooh cool, still hope to be able to visit that one year; enjoy! |
| 18:19 | <wanderview> | Domenic: Thinking about my next partitioning PR, I think we need to populate environment's top-level origin for SharedWorker. In implementation, though, we only populate the origin with the top-level site. Its the only consistent value to use when top-level site partitioning is in use. (We don't want different values depending on which document first created the worker.) Does that sound like a reasonable approach to take in the spec as well? |
| 18:57 | <Domenic> | wanderview: I think so. I'd prefer to get annevk's feedback, but from what I can tell from e.g. https://github.com/whatwg/html/pull/5491#issuecomment-638989208 and related comments, we have so far punted on defining top-level origin for workers until storage partitioning was in place, and we knew that we would eventually need it to ensure that e.g. network caches work well. Or at least, we would need enough info to feed into "obtain a storage key" / "obtain a storage key for non-storage purposes". Which I guess is just the site. What's unclear to me is whether this means "top-level origin" is not a good primitive, and if so what we would do about it. But e.g. it is used in origin form for window-specific things like showPicker() or COOP enforcement. So maybe the best we can do is say that it's sometimes an origin and sometimes a scheme-and-host, and maybe rename it slightly to reflect that? |
| 19:04 | <wanderview> | right, this issue only effect SharedWorker and ServiceWorker... but right now I'm not aware of anything that actually depends on top-level origin specifically instead of top-level site |
| 19:04 | <wanderview> | its possible some extension stuff in chromium would see slightly different behavior for requests coming from those workers |