I’m experiencing an issue with pages on a specific website freezing/responding slowly. I don’t have any autofill setup on this site, but when it completely freezes, firefox gives a notification saying that Kee is slowing down the browser.
The specific site I’m experiencing this on is 4chan with very active posts (1000+ replies). It’s perfectly stable and usable with smaller posts (100~ replies) It may be important to mention I’m using the userscript 4chanX via Tampermonkey.
I disabled Kee and tested and the site was smooth as butter. I can’t really do a comparison with the userscript disabled since there really isn’t much of any “active” elements on the site without it.
Since this is a highly specific issue, I’m more than happy to provide any additional logs and such. I’m not sure what would be helpful to provide so far though. I did a “performance recording” via firefox with it enabled and disabled that I can include if it’s helpful. Console isn’t reporting anything obvious.
+1,
I’m a dev by trade, yesterday noted chrome eating cpu and becoming unresponsive. Switched to firefox, same thing page loading was ugly slow but firefox provided helpful notification that it is Kee extension which is the culprit (page was local web page I’m building, so http://localhost/blabla). After disabling Kee extension in everything is smooth again.
Page slow down was happening regardless if Keepass was on/off (my first thought was that extension was hacked so I turned off Keepass, page was still slow even after browser restart).
Was there an update? Just wondering why did the once stable extension change it’s behavior so drastically I had to disable it?
While I appreciate your work, it is unusable in it’s current form.
If you have a Firefox performance profiler file saved, you should be able to upload it to https://profiler.firefox.com/ and then share a URL to see if anyone can spot any clues about where the slowdown is occurring.
I can’t reproduce the problem on a random 4chan post with > 1000 replies so perhaps there are other factors at work. Either a specific configuration of Kee, your web browser or 4chan might impact exactly which operations Kee has to perform in order to detect sign-in forms on a website, and how often this has to be done.
I can’t really do a comparison with the userscript disabled since there really isn’t much of any “active” elements on the site without it.
I don’t fully understand this but I’ve never seen 4chan before so perhaps that’s unsurprising. If the problem only occurs with a userscript extension, we will find it hard to reproduce and identify which extension and which component of that extension is responsible for the bulk of any CPU usage.
I’m not aware of any updates/changes to Kee that would notably affect its performance on any web pages, but then again, if I were aware of such a change, I wouldn’t have made it without some sort of opt-out setting and/or public announcement about the risk.
Hi, thanks for the response. I wasn’t aware of that page, perfect. Yes, it’s dependent on the userscript to experience so I do understand that this isn’t a pleasant thing to figure out. I hadn’t really read threads with such high post counts until recently to figure out when this first appeared sadly.
Original recording (not sure if I refreshed the page after disabling Kee)
Kee Disabled: https://share.firefox.dev/3ciCitx
Kee Enabled: https://share.firefox.dev/33LWX5x
Aaaand lastly, a link to 4chanX, since I hadn’t included that in my original post and it’s kind of key to testing the issues for yourself: https://github.com/ccd0/4chan-x
The profiles suggest that the new “collectLabels” function which is part of some recent and planned improvements to form filling accuracy is taking an unacceptable amount of time with the specific DOM structure that you end up with on 4chan while using this userscript.
Perhaps we can employ some sort of limit in that function to exclude such complex web pages from these form filling improvements.
I’ve added a few performance improvements including one to work around what appears to be a problem with the performance of the NodeList.length property in Firefox. I don’t have a good test case to verify this helps in your situation but I will let you know when there is a beta version available for you to try out.