| 01:18 | <sideshowbarker> | @lwarlow:igalia.com: Wondering how come you didn't also end up being the one to do the Gecko implementation for Trusted Types |
| 10:15 | <Noam Rosenthal> | I was thinking about the focusin/focusout thing with moveBefore. Perhaps the right thing to do is to fire only focusin, and only if the element is indeed reparented (not e.g. reordered).We anyway don't fire blur/focusout when an element is removed |
| 10:16 | <Noam Rosenthal> | annevk: keithamus smaug WDYT? |
| 10:31 | <keithamus> | Seems reasonable to me. |
| 10:54 | <bkardell> | @lwarlow:igalia.com: Wondering how come you didn't also end up being the one to do the Gecko implementation for Trusted Types |
| 10:57 | <sideshowbarker> | Not to answer for him, but work began somewhat in parallel so that would've been difficult |
| 10:59 | <bkardell> | Yes, unless I'm mistaken |
| 10:59 | <freddy> | I think "no", but this does not seem to be the right forum to discuss :) |
| 11:02 | <bkardell> | @fbraun:mozilla.org: you'd know better i guess đ |
| 11:03 | <sideshowbarker> | I think "no", but this does not seem to be the right forum to discuss :) |
| 12:19 | <sideshowbarker> | https://github.com/LadybirdBrowser/ladybird/pull/2033/files#diff-09f2556b71c3f11db8fcda94914e8207e8268c667dc63a1aa6d2e906034439abR2241-R2312 is how I ended up implementing it. It implements what seems to be what the spec intends, if not strictly what the spec states. That only implements the computation for the âembedded controlsâ cases. And for that I didnât end up needing to consult the the HTML-AAM spec at all. I will when I need to implement handling for some cases like |
| 13:30 | <smaug> | Noam Rosenthal: I assume you mean also focus |
| 13:31 | <Noam Rosenthal> | Noam Rosenthal: I assume you mean also focus |
| 13:31 | <smaug> | Why is bubbling important? |
| 13:31 | <smaug> | Events have capture phase |
| 13:32 | <Noam Rosenthal> | yea I guess capture matters just as much |
| 13:32 | <Noam Rosenthal> | I was thinking of focusin as where you'd put your general-purpose focus tree change catchers |
| 13:33 | <Noam Rosenthal> | but it's not material, I think re-firing focus/focusin (but not blur/focusout) when a focused element is reparented is reasonable-ish |
| 13:33 | <smaug> | (I'd assume focus listener being used for that more often. But I have no data to back up my guess đ ) |
| 14:25 | <Noam Rosenthal> | smaug: regardless of focus vs. focusin, WDYT of the idea of firing only the "in" part when reparenting a focused element? |
| 15:05 | <smaug> | I would say that is a bit surprising, but if removing focused element doesn't fire blur, probably fine. But for consistency, should focus/focusin first always when moving? |
| 15:25 | <Noam Rosenthal> | I would say that is a bit surprising, but if removing focused element doesn't fire blur, probably fine. But for consistency, should focus/focusin first always when moving? |
| 15:26 | <Noam Rosenthal> | or you mean when reordering but not reparenting? |
| 16:03 | <smaug> | Noam Rosenthal: the latter. Certain cases might rely on the ordering. Like styling |
| 16:03 | <smaug> | (and just having consistency is good in general) |
| 16:15 | <Noam Rosenthal> | SGTM |
| 17:37 | <Noam Rosenthal> | OK I agree it's a bit surprising, but it's perhaps the least error prone. we fire focus/focusin for a moved element, as if we've blurred and refocused it. No blur/focusout events. Also seeking feedback from annevk about this. Other option is still to not fire these at all and rely on userland |