| 06:36 | <annevk> | Possibly Private/Local Network Access changes this? Been a while since I looked. |
| 10:37 | <Noam Rosenthal> | Yes, there are special preflights for PNA: https://developer.chrome.com/blog/private-network-access-preflight#preflight_requests |
| 10:59 | <Jake Archibald> | annevk: Safari blocks http localhost iframes inside https pages. Chrome and Firefox don't. Given that localhost should be treated as secure, this seems like a bug. Am I missing something? |
| 11:00 | <Jake Archibald> | https://bumpy-repeated-cover.glitch.me/ - quick test page, but you'll need to run a local server on 8080 that contains index2.html |
| 11:09 | <annevk> | Jake Archibald: we currently don't enforce that localhost is localhost, that's something we need to fix still |
| 11:10 | <Jake Archibald> | annevk: Oh, so is 127.0.0.1 likely to work? |
| 11:12 | <Jake Archibald> | ah, no, that doesn't work either |
| 11:34 | <annevk> | Hmm, that does seem like something that might be easier to fix. Are you willing to file a bug for just that? (There already are some for localhost.) |
| 11:52 | <Jake Archibald> | From https://bugs.webkit.org/show_bug.cgi?id=171934#c96, it seems like it's a difference of opinion with webappsec. I added a couple of comments about our use-case |
| 13:31 | <annevk> | Oh right. I had forgotten about P/LNA. Makes sense. Although I wonder if P/LNA still contains localhost protection. |
| 14:38 | <Dominic Farolino> | So smaug annevk what do you we think about stage 3 for atomic move? I'm sure there are small things that will fall out during review, but I think generally we agree on the shape of the processing model? |
| 14:45 | <smaug> | I think it needs another round of reviews, given that there were some rather obvious issues still couple of days ago. |
| 14:46 | <Dominic Farolino> | smaug: One of the comments is waiting on your feedback I believe |
| 14:46 | <Dominic Farolino> | (range updates) |
| 14:48 | <smaug> | sure, the range/selection part. But things like not handling Shadowroot or having wrong assumptions how ranges work were a bit surprising |
| 14:48 | <Dominic Farolino> | How do you feel about https://github.com/whatwg/dom/pull/1307#discussion_r1838738862 |
| 14:48 | <Dominic Farolino> | Right, I don't think stage 3 is "all bugs are fixed" heh |
| 14:48 | <smaug> | ...which is why I'd prefer another round of reviews |
| 14:49 | <Dominic Farolino> | OK, I'd appreciate your thoughts on https://github.com/whatwg/dom/pull/1307#discussion_r1838738862: keeping the container preservation approach except for when we cross the shadow boundary |
| 14:49 | <Dominic Farolino> | Or do you feel pretty set on not doing nothing special for Ranges during moveBefore() (treating them like remove + insert instead) |
| 14:49 | <Dominic Farolino> | The downside of that is that we never preserve selection if the selection range's endpoints move around |
| 14:50 | <Dominic Farolino> | Not the end of the world, but "better" selection preservation feels nice |
| 14:51 | <smaug> | That is a bit tricky one. In case of implementation supporting multiple ranges in selection, or using live ranges for highlights, some ranges might survive the move, and some wouldn't |
| 14:51 | <smaug> | it might lead to a bit surprising results |
| 14:53 | <Dominic Farolino> | Do any implementations support multiple ranges that contribute to a selection? I don't think that's allowed: https://w3c.github.io/selection-api/#responding-to-dom-mutations:~:text=Each%20selection%20can%20be%20associated%20with%20a%20single%20range |
| 14:53 | <smaug> | Gecko supports multiple ranges |
| 14:54 | <smaug> | (and other implementers have every now and then said it would be nice to support) |
| 14:55 | <Dominic Farolino> | Hmm, that feels like something we could deal with it if were to become standardized. Until then, I guess it's an implementation-specific thing to work around. I'd hate to make a decision about moveBefore() because of non-standardized impl quirks that we can't think through because we don't have a spec. |
| 14:55 | <smaug> | But hightlight anyhow supports multiple ranges |
| 14:56 | <smaug> | So, whether or not selection supports multiple ranges isn't too relevant here. |
| 14:59 | <Dominic Farolino> | OK so your concern is that if we only preserved selection when it is entirely inside a moved container node, then some ranges in a highlight will get reset (in the same way they do during remove()), and others will completely survive, right? |
| 15:00 | <smaug> | Right. And that would be quite surprising, I think. |
| 15:00 | <Dominic Farolino> | I.e., that would be surprising |
| 15:01 | <Dominic Farolino> | How about the more aggressive preservation tactic where we always try and preserve the range (by allowing its start/end containers to move via moveBefore) — unless the start/end get inverted, in which case we collapse the range |
| 15:01 | <Dominic Farolino> | I think that could still lead to some cases where some ranges survive and others get collapsed, but it feels a little more predictable since you know your start and end containers, maybe? |
| 15:02 | <Dominic Farolino> | (and start/end being inverted -> resulting in collapse feels pretty expected) |
| 15:02 | <smaug> | or if we move something across light/shadow trees... |
| 15:02 | <Dominic Farolino> | yeah... it does get complicated |
| 15:03 | <Dominic Farolino> | We could punt on this (don't handle Ranges specially during moveBefore()) until maybe users decide they care enough... |
| 15:05 | <smaug> | That might be easier for now. And if needed, add later some options to moveBefore. |
| 15:07 | <Dominic Farolino> | I'd like to (& framework authors agree) avoid a bag of options for the API in the future if possible. So if we decide to change this in the future, I'd really try and shoot for just changing the behavior inside this API straight-up |
| 15:17 | <smaug> | That might be doable. One might be able to also provide some helper APIs for Range to move it around from one subtree to another (or in moveBefore case, re-initialize the old state after move). |
| 15:28 | <Noam Rosenthal> | We generally preserve element-specific state (frame window, focus, animation, dialog/fullscreen/popover), I think it makes sense to not automatically preserve state that depends on multiple elements, such as ranges, and design something separate for that later on if the need arises, not necessarily as a node-specific API |
| 15:28 | <annevk> | FWIW, I'm out this week (see Bluesky). I also have the feeling we're still not quite on the same wavelength with regards to when something is eligible for Stage 3. I think that warrants some further meta discussion as it would be good if we were all on the same page. |
| 15:29 | <Noam Rosenthal> | We generally preserve element-specific state (frame window, focus, animation, dialog/fullscreen/popover), I think it makes sense to not automatically preserve state that depends on multiple elements, such as ranges, and design something separate for that later on if the need arises, not necessarily as a node-specific API |
| 18:57 | <Andreu Botella> | Hey, the only cases where a custom element's lifecycle callbacks can be called with the reaction stack being empty are involving user editing, right? |