The extension does not freeze some pages on the MDPI website.
The extensions freezes pages on the MDPI website such as this one, and the only solution is to stop it. This happens regardless of whether the desktop app is running or not, and if it is running, regardless of whether the database is unlocked or not (I have an account on MDPI, but since the issue occurs even when the desktop app is not running I don't think it's relevant).

I noticed that after I stop the extension (as suggested by Firefox), the browser loads other elements of the page that it evidently couldn't load before. I'm probably wrong, but there could be an issue with the interaction between the extension and these elements of the page.
KeePassXC - {2.6.0}
KeePassXC-Browser - {1.6.6}
Operating system: Win
Browser: Firefox/Chromium
Seems it's the rocketlauncher script that makes constant changes to the body element. I need to figure out how to reduce these kind of triggers. As a workaround you can disable the extension for the page via Site Preferences if you don't need it.
I would just focus on the refactor work you are doing and then address it following testing of that new code.
I even get the message on a page for which the extension is supposed to be disabled. Extension version 1.6.6.
BTW, I find the 'Ignore' in the heading of the site preferences table very confusing. Does it mean that the setting below is ignored?
@matthiasschroder It means all extension features, including the dynamic input field detection are disabled for the site.
I've been doing some major refactoring for 1.7.0 and I haven't seen any slowdowns with that develop branch. So this will be fixed with that release.
@varjolintu That's what I thought it would mean, but I still find it confusing. I read the table and I see as heading 'Ignore' and as content 'Disable all features'. So at first sight this means that the 'disable all features' will be ignored.
And thanks for taking care of the issue that this ticket is about :)
The reason why the slowdowns happen is that MutationObserver doesn't seem to block script elements properly. And there's a script that runs over 20 mutations simultaneously every 2-3 seconds. But this is just one reason of the slowdowns. I'll push the refactor PR soon for testing, and it would be helpful for anyone with these issues to test it also.
The refactor seems to solve the problem for me. I have had constant "slow down" errors when accessing an internal installation of OctoPrint. Previously, the only way I could get it to work was disabling the extension. With the refactored code, I get no errors and the page is very responsive.
>
>
The refactor seems to solve the problem for me.
Same for me, works like a charm. Thanks a lot for looking into this.
Most helpful comment
The refactor seems to solve the problem for me. I have had constant "slow down" errors when accessing an internal installation of OctoPrint. Previously, the only way I could get it to work was disabling the extension. With the refactored code, I get no errors and the page is very responsive.