| 00:46 | <Domenic> | I am in favor of treating all nulls the same... the platform has enough null-ish things. |
| 05:28 | <annevk> | I think if you need to distinguish two nullish values in those cases you should start out with your variable being undefined. If you really need the equivalent of any-or-nothing I'm not sure. Maybe a side boolean? But maybe also reconsider the general API shape. |
| 08:56 | <Jake Archibald> | It seems like Google and Mozilla blocked it. |
| 10:12 | <Noam Rosenthal> | Looking at the term "similar-origin window agent" (https://html.spec.whatwg.org/multipage/webappapis.html#similar-origin-window-agent). In a nested cross-origin iframe case like A1 -> B -> A2, is there a way where A1 can get script access to A2's window? |
| 10:15 | <Noam Rosenthal> | oh I guess window[name]. Weird old stuff I forgot about |
| 10:19 | <Ms2ger> | annevk: what, are you holding me responsible for bugs I introduced now? :) |
| 10:33 | <annevk> | Ms2ger: git blame is a wonderful thing. |
| 15:09 | <Domenic> | Looking at the term "similar-origin window agent" (https://html.spec.whatwg.org/multipage/webappapis.html#similar-origin-window-agent). window[0][0] so you don't even have to know the names, just enumerate over integers until you find something that doesn't throw when calling .document |
| 16:00 | <Noam Rosenthal> | Domenic: yea, I meant in general the window[...] feature... thanks |
| 16:35 | <Noam Rosenthal> | smaug: see https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/loader/frame_loader.cc;l=388?q=frame_loader.c |
| 16:36 | <Noam Rosenthal> | We're unloading the document with will_commit_new_document_in_this_frame === false |
| 16:36 | <smaug> | Noam Rosenthal: and that gets called at what point when iframe is removed from DOM |
| 16:37 | <Noam Rosenthal> | smaug: that would happen in https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/dom/container_node.cc;l=642;bpv=1;bpt=1?q=container_node.cc |
| 16:38 | <smaug> | thanks! |
| 16:38 | <Noam Rosenthal> | so it's right before doing the actual DOM remove. the iframe would still appear connected if you query the parent's DOM during the pagehide event listener |
| 16:40 | <smaug> | looks like the code is pretty much as hacky as in Gecko 😛 |
| 16:41 | smaug | vaguely recalls fixing some crashes around iframe removal...maybe 15 years ago |
| 16:42 | <Noam Rosenthal> | yea this synchronous removal stuff is nasty. For the synchronous blur event firing we have so much special-case code |
| 17:00 | <Luke Warlow> | Sorry for dropping out there my headset ran out of battery right as I was going to speak |
| 17:01 | <smaug> | I'll need to check all the callers of AddScriptRunner. Gecko has > 100 of those |
| 17:01 | <smaug> | (many of them don't affect anything on the web though) |
| 19:53 | <smaug> | Dominic Farolino: actually, I don't know how the insertion step model works in case of mutations. Say, you have an element and it has 3 child elements. That subtree root element is inserted to document tree. Now child 1 has insertion steps which run some script which removes the child and adds it to be the last of the child nodes. So child list is now 2, 3, 1. Do the insertion steps get run on 1 again, because it is now after 2 and 3? |
| 19:53 | <smaug> | The pr doesn't explain this |
| 20:14 | <smaug> | I mean, the insertion step would certainly run when 1 is added back to DOM, but would insertion step run again when iterating through the children of the subtree root. |