Bug reported by a nightmy community member. Since last week, Nightly is unusable on pages with a lot of forms (180 forms in this case) and form input fields on a page on his intranet. 53 is fine. Since this is in an intranet, he sent me a reduced page in which we can reproduce the bug. STR: 1/ Load the html file attached to this bug 2/ Click on various input fields in the page ER: input fields get focused AR: 100% CPU for several seconds then the input gets the focus using mozregression I was able to find out that this is caused by out new form autofill feature: mozregression --good 2017-06-05 --bad 2017-06-10 --repo autoland 6:38.72 INFO: Last good revision: 6175f32bed68450cf039f42399802243f0e4898d 6:38.72 INFO: First bad revision: 60afe5db03953126ca3f6a40e7a3aab81e425556 6:38.72 INFO: Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=6175f32bed68450cf039f42399802243f0e4898d&tochange=60afe5db03953126ca3f6a40e7a3aab81e425556 A workaround is to set extensions.formautofill.heuristics.enabled to false in about:config

Matt, it seems that Bug 1368872 caused this performance regression on forms, could you have a look? Thanks

Looks like I can reproduce on nightly but not on 55.0b1

This has started to happen in Nightly between the day june 9 and june 12

Autofill isn't built in 55. Redirecting to Sean Lee who implemented bug 1368872. Sean, please make sure we're only identifying fields in the specific form that was focused, not all forms on the page.

Hey MattN, the patch is for identifying the focused form. Please review it. Thank you.

Comment on attachment 8877842 [details] Bug 1372843 - Identify the focused form only when applying heuristics. https://reviewboard.mozilla.org/r/149268/#review153762 ::: browser/extensions/formautofill/FormAutofillContent.jsm:443 (Diff revision 1) > identifyAutofillFields(doc) { > this.log.debug("identifyAutofillFields:", "" + doc.location); > > if (!this.savedFieldNames) { > this.log.debug("identifyAutofillFields: savedFieldNames are not known yet"); > Services.cpmm.sendAsyncMessage("FormAutofill:InitStorage"); > } > > let forms = []; > > + let focusedForm = doc.activeElement.form; > + focusedForm = focusedForm ? focusedForm : doc; > + > // Collects root forms from inputs. > - for (let field of FormAutofillUtils.autofillFieldSelector(doc)) { > + for (let field of FormAutofillUtils.autofillFieldSelector(focusedForm)) { This seems a bit hacky… Is there a reason to leave the method taking a document? I think it would be clearer and more efficient to change this method to take a field as an argument and only construct a FormAutofillHandler for the rootElement of the passed field.

Comment on attachment 8877842 [details] Bug 1372843 - Identify the focused form only when applying heuristics. https://reviewboard.mozilla.org/r/149268/#review153762 > This seems a bit hacky… Is there a reason to leave the method taking a document? I think it would be clearer and more efficient to change this method to take a field as an argument and only construct a FormAutofillHandler for the rootElement of the passed field. The latest patch refactors `identifyAutofillFields` function. I use `form.elements.length` to determine if the form is changed, so the unnecessary `formHandler.collectFormFields` can be skipped.

Comment on attachment 8877842 [details] Bug 1372843 - Identify the focused form only when applying heuristics. https://reviewboard.mozilla.org/r/149268/#review154122 Thanks for jumping on this Sean! ::: browser/extensions/formautofill/FormAutofillContent.jsm:452 (Diff revision 3) > this.log.debug("identifyAutofillFields: savedFieldNames are not known yet"); > Services.cpmm.sendAsyncMessage("FormAutofill:InitStorage"); > } > > - let forms = []; > - > + if (!FormAutofillUtils.isFieldEligibleForAutofill(element)) { > + this.log.debug("Not a eligible field."); Nit: s/a/an/ ::: browser/extensions/formautofill/FormAutofillHandler.jsm:42 (Diff revision 3) > /** > * DOM Form element to which this object is attached. > */ > form: null, > > + _numOfFormControls: 0, Nit: `_formFieldCount` avoids "num" and "of" ::: browser/extensions/formautofill/FormAutofillHandler.jsm:81 (Diff revision 3) > AUTO_FILLED: "-moz-autofill", > // highlighted && grey color text > PREVIEW: "-moz-autofill-preview", > }, > > + get isFormChangedSinceLastCollect() { Nit: Collection ::: browser/extensions/formautofill/FormAutofillHandler.jsm:82 (Diff revision 3) > // highlighted && grey color text > PREVIEW: "-moz-autofill-preview", > }, > > + get isFormChangedSinceLastCollect() { > + // When the number of Form controls is the same with last collecting, it nit: s/Form/form/ ::: browser/extensions/formautofill/test/unit/test_markAsAutofillField.js:76 (Diff revision 3) > - FormAutofillContent.identifyAutofillFields(doc); > + let element = doc.getElementById(testcase.targetElementId); > + FormAutofillContent.identifyAutofillFields(element); I personally would have use the shared querySelector to find the first field but okay ::: browser/extensions/formautofill/test/unit/test_onFormSubmitted.js:114 (Diff revision 3) > - FormAutofillContent.identifyAutofillFields(MOCK_DOC); > + let element = MOCK_DOC.getElementById(TARGET_ELEMENT_ID); > + FormAutofillContent.identifyAutofillFields(element); Same here

Pushed by lchang@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/e9f06d11a468 Identify the focused form only when applying heuristics. r=MattN

I tried to reproduce this bug using old Nightly from 2017-06-10 or Nightly from 2017-06-14 but I could not reproduce. Also using latest Nightly (2017-08-16), and beta 56.0b3 on Windows 10 x65, Ubuntu 16.04 x64 and macOS 10.12 I could not see more than 10% cpu usage. On affected builds I used the demo from comment 0 and I clicked on various inputs from it, but I didn't get a higher value then 50% (I got this value on Ubuntu) from the CPU measuring tool so that case is isolated though and far from the 100% you guys got. Julien since you were able to reproduce this in the first place can you please verify it's fixed on Fx 56beta3 build?

I reproduced this again with https://archive.mozilla.org/pub/firefox/nightly/2017/06/2017-06-09-10-02-51-mozilla-central/firefox-55.0a1.en-US.linux-x86_64.tar.bz2 Then tried 56.0b3, and the issue isn't reproducible there.

(In reply to Julien Cristau [:jcristau] from comment #17) > I reproduced this again with > https://archive.mozilla.org/pub/firefox/nightly/2017/06/2017-06-09-10-02-51- > mozilla-central/firefox-55.0a1.en-US.linux-x86_64.tar.bz2 > > Then tried 56.0b3, and the issue isn't reproducible there. Thanks Julien, marking the bug accordingly!