Page with no url macth but many textboxes/inputs slow

In Firefox and chrome I am getting warnings about then addon/extension causing slow downs. The page has quite a few inputs on it. This page has no matching URLs for this page when clicking the extension button in each browser.

Is there some way I can prevent whatever check is being done on forums like the URL matches done when pressing kee extension button?

There should already be quite strict limits on the number of forms and fields we look at but perhaps there are some edge cases we’re not handling well. We can’t really do anything about this without some clear instructions on how to reproduce the issue on a machine with development tools installed… unless you are a developer yourself and would like to investigate and propose a solution?

This might relate to the recent issue that someone was having with some particular configuration of 4chan: Experiencing severe Kee related slowdown on website

Just had a chance too fully dive into this today. The issue is the for loop in getFormFields function is slowing things down. I did profile it and the link for that is https://share.firefox.dev/3mQzjgM. However I think the console log helps show the issue the best.

The console log is:
Finding matches in a document. readyState: complete common.js:16:1111
findMatches processing 1 forms common.js:16:941
about to get form fields common.js:16:941
processing field with domtype text… 3 common.js:16:941
processing field with domtype select-one… 2 common.js:16:941
processing field with domtype text… common.js:16:941
processing field with domtype select-one… common.js:16:941
processing field with domtype text… 4 common.js:16:941
processing field with domtype radio… 4 common.js:16:941
processing field with domtype select-one… common.js:16:941
processing field with domtype text… common.js:16:941
processing field with domtype select-one… 2 common.js:16:941
processing field with domtype text… common.js:16:941
processing field with domtype select-one… common.js:16:941
processing field with domtype text… 3 common.js:16:941
processing field with domtype radio… 14 common.js:16:941
processing field with domtype text… 2 common.js:16:941
processing field with domtype radio… 2 common.js:16:941
processing field with domtype text… 6 common.js:16:941
processing field with domtype textarea… 2 common.js:16:941
processing field with domtype checkbox… common.js:16:941
processing field with domtype textarea… common.js:16:941
processing field with domtype checkbox… common.js:16:941
processing field with domtype textarea… common.js:16:941
processing field with domtype checkbox… common.js:16:941
processing field with domtype textarea… common.js:16:941
processing field with domtype checkbox… common.js:16:941
processing field with domtype text… 9 common.js:16:941
processing field with domtype textarea… common.js:16:941
processing field with domtype checkbox… 6837 common.js:16:941
processing field with domtype text… 2 common.js:16:941
processing field with domtype select-one… common.js:16:941
processing field with domtype checkbox… 2202 common.js:16:941
processing field with domtype text… 7 common.js:16:941
processing field with domtype select-one… common.js:16:941
processing field with domtype textarea… 13 common.js:16:941
processing field with domtype text… 4 common.js:16:941
processing field with domtype textarea… 13 common.js:16:941
usernameIndex: -1 common.js:16:941
actualUsernameIndex: 0 common.js:16:941
otherFields.length:9147 common.js:16:941
Lost interest in this form after finding too many fields common.js:16:941

The console log shows that check for number forum fields doesn’t even happen till much latter on but that many inputs have been added to a list. Would you consider adding a if statement of “if (i === 50) { break; }” to the getFormFields loop?

Thanks for looking into it in more detail.

I think I’d prefer that we focus on the collectLabels function first as I just mentioned in Experiencing severe Kee related slowdown on website

Although this is not shown up in your profile, I’m not sure whether that could be due to a limitation of the profiler and it is one of the few bits of code around this part of the extension that has changed recently so it may well be the cause of your problems too. If changing that function doesn’t help, we can consider introducing additional handicaps at other stages of the getFormFields loop as you suggest.

I’ve added something similar to your suggestion in the getFormFields function as part of a few performance improvements. So hopefully there will be fewer executions of collectLabels now as well as each execution of it performing faster. I don’t have a good test case to verify this but I will let you know when there is a beta version available for you to try out.

Checking github seen that there was version 3.6.4/commit 21efb9d. I installed the developer edition of Firefox to test since 3.6.4 is unsigned. Having the number of form fields checked much earlier on improved the performance greatly. I no longer see warnings or have the lags as before. Thanks for the change.