Luis Herranz

Maybe Safari and Chrome are doing different things? For me [adding the `change` event](https://github.com/fregante/GhostText/pull/214) fixed the problem in Chrome.

Ok, I've been debugging GitHub's code and you're absolutely right, I ended up in the same place: ```ts // Observe required fields and validate form when their validation state //...

Ok, saw it. It's because there is also another listener in the form for `change` events that also enables/disables the button: ```ts // Install validation handlers on a form. function...

In my opinion both sound a bit hacky. Sorry, I thought this had a simple fix. The only solution that seems rather "safe" to me is to apply this fix...

Hmm... I guess the problem is when to retrigger it again, don't you think? If we just swallow the `blur` event then we may break sites that depend on it...

Ok, I guess it's worth a try 🙂 Do you know of any other sites that depend on this apart from GitHub?

I have started playing with this in my `site-transformations` branch in case anyone else wants to try. https://github.com/fregante/GhostText/compare/main...luisherranz:site-transformations For the HTMLMarkdown transformation I'm using `unified` (remark/rehype). The goal is not...

> if connected Comp changes overtime Under what circumstances will the connected Comp component change over time? Can you trace that down to a specific component to understand what's going...

Even though I don't fully understand the problem, if those flags indeed cause a memory leak, these should fix it: - https://github.com/frontity/frontity/pull/946 @erdigokce, @DonKoko: would you mind testing it out?...

It's just a bump from the previous versions. It doesn't have any real meaning. You can see the changelogs here: - [core](https://github.com/frontity/frontity/blob/beta/packages/core/CHANGELOG.md) - [frontity](https://github.com/frontity/frontity/blob/beta/packages/frontity/CHANGELOG.md)