| 09:17 | <jub0bs> | * There's more. Further down, we're encouraged to responds with
|
| 09:19 | <annevk> | jub0bs: you have to know that Set-Cookie is never used for the response, whether middleware has that information depends |
| 09:20 | <annevk> | Alice: happy to meet next week, I'm usually available 9-5 Berlin time. Could probably make 8:30 work. Earlier would be tricky, but maybe doable for a one-off. |
| 10:33 | <jub0bs> | annevk: I guess what I'm trying to figure out is, under the assumption that there are legitimate cases to add Vary: Cookie to a response, should it be the responsibility of CORS middleware? Jake's answer (according to that section of his post) seems to be "yes". But that means CORS middleware must inspect the response to the actual request to decide what to do. None of the existing CORS middleware I've reviewed currently do that; they inspect the actual request, but not the response to it. That's why I'm surprised by Jake's post. |
| 10:46 | <jub0bs> | annevk: Unless I missed something, the Fetch standard doesn't provide any guidance about that. The only relevant passage I found only mentions tuning the CORS headers according to the CORS request, not its response:
My emphasis. |
| 11:04 | <annevk> | I don't think that sentence considers middleware as separate software from the server. |
| 12:46 | <jub0bs> | annevk: I see, but I'm afraid I need more guidance 😀 |
| 12:47 | <jub0bs> | Another element, which contradicts Jake's view, is this SO response by sideshowbarker : https://stackoverflow.com/a/53248240/2541573
|
| 13:32 | <annevk> | jub0bs: I don't think there's a contradiction there; again, that's assuming the entire non-client-side knows what it's doing |
| 13:33 | <annevk> | jub0bs: the middleware situation is somewhat unique in that the middleware doesn't know whether a response flagged as * would also sometimes use Set-Cookie |
| 13:34 | <annevk> | jub0bs: or even if it didn't use Set-Cookie itself, that it would take Cookie request headers into account somehow |
| 14:07 | <jub0bs> | annevk: Now I'm no longer sure that a CORS middleware library can exist. 😟 It seems to require a lot of information about how the request is handled and the response composed. |
| 14:54 | <annevk> | jub0bs: I think you can implement some kind of defaults and perhaps log a warning if they didn't explicitly declare they're not varying on Cookie headers |
| 14:54 | <annevk> | jub0bs: cause in principle the origin server would have to use Vary: Cookie if they did indeed vary on Cookie, right? |
| 14:59 | <dlrobertson> | Domenic: I have questions about https://github.com/web-platform-tests/wpt/pull/37018#discussion_r1025934637 |
| 15:00 | <dlrobertson> | Per https://drafts.csswg.org/cssom-view/#scrolling-events:
|
| 15:01 | <dlrobertson> | I'm uncertain how we'd keep the event handler content attribute usable without keeping onscrollend where it is (with forwarding behavior) |
| 15:02 | <dlrobertson> | I guess we could change cssom-view to specify "If target is Document or document.body, ... that bubbles at target" |
| 15:06 | <dlrobertson> | Actually I think we'd want document.scrollingElement not document.body there |
| 15:20 | <Domenic> | dlrobertson: I don't really understand the problem? If the "otherwise" case has the target being the body, then, <body onscrollend="foo()"> should call foo(). |
| 15:29 | <dlrobertson> | yeah, but it sort of requires breaking the first case right? If we expect scrollend for document.scrollingElement.scroll(...) to fire to document.scrollingElement, then I think the first case is never hit |
| 15:30 | <dlrobertson> | and as a result, window.onscrollend is never used |
| 15:30 | <dlrobertson> | I could be thinking too much on the implementation side |
| 15:31 | <Domenic> | Doesn't it bubble to eventually hit window.onscrollend? |
| 15:32 | <dlrobertson> | currently only if the target is Document |
| 15:32 | <Domenic> | I thought events on body bubbled to window eventually... |
| 15:33 | <dlrobertson> | I thought events on body bubbled to window eventually... |
| 15:33 | <Domenic> | Yeah, all events that bubble go from document to window |
| 15:33 | <Domenic> | And body to document |
| 15:33 | <Domenic> | Look at each instance of https://dom.spec.whatwg.org/#get-the-parent |
| 15:35 | <Domenic> | So it looks like if the viewport is scrolled, then the Document itself goes into pending scroll event targets. So it bubbles Document -> Window. If scrollingElement (= html element, I think) gets scrolled, then it bubbles html element -> Document -> Window. But event.target === the html element. Similarly if the body element gets scrolled, then it bubbles body -> html -> Document -> Window, with event.target === the body element. |
| 15:36 | <Domenic> | Oh wait, second case doesn't bubble |
| 15:36 | <Domenic> | So I guess only the Document -> Window case bubbles. Kinda strange, but whatever... |
| 15:39 | <dlrobertson> | I think that's because we currently expect forwarding behavior, I'm starting to think the first case should be expanded to Document or Document.scrollingElement |
| 15:41 | <Domenic> | Yeah, I guess it's strange that it's (according to that spec) possible to have some entries in the pending scroll event targets that are Documents, and some which are the scrolling element for the document. Not sure that distinction should exist. |
| 15:45 | <dlrobertson> | Ah that's a great point! |
| 15:49 | <dlrobertson> | I need to do a lot more reading to get a better grasp on it, but I might be headed in the right direction now |
| 15:49 | <dlrobertson> | key word might |
| 15:59 | <annevk> | If we're really ending up with ::part() and :--state that's pretty sad |
| 20:01 | <sideshowbarker> | Anybody know if there’s some reason for dialog.showModal() not working in Firefox Nightly despite working just fine in Firefox 107? |
| 20:03 | <sideshowbarker> | see https://github.com/matrix-org/matrix-public-archive/issues/145 — I ran into this case where some code works as expected in Firefox 107, but in Firefox Nightly, it throws Uncaught TypeError: this.dialogNode.showModal is not a function |
| 20:08 | <smaug> | sefeng: ^ |
| 20:16 | sefeng | will talk to sideshowbarker privately to not spamming this room. |