Reporter

Description

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:93.0) Gecko/20100101 Firefox/93.0

Steps to reproduce:

We have a large HTML table with about 200 rows, and 10 columns. The script is pulling a lot of data but generally takes about 3-5 seconds to load. This is on v93. Since v94 this has changed to over 1 minute. Thought it was our site until I went back to v93 on which it works.

Actual results:

I opened a thread on FireFox Support https://support.mozilla.org/en-US/questions/1364203. Was advised to use mozregrssion which I did. The results are on the thread. The help suggestion (Until it's fixed you can enter about:config in the URL bar and set "layout.css.cascade-layers.enabled" = false.) did not work although it did improve it.

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Core & HTML' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

That regression range makes no sense, cascade layers are shipping in Firefox 97, and weren't implemented in Firefox 94.

Can you attach about:support? Do you have a URL that reproduces the issue? The 3s vs. minutes difference is massive.

Reporter

Comment 3

Bear in mind I am only a user.

What is about:support. Which version(s) do you want it from.

It is happening inside of our CRM. It would be difficult to provide you with access. I am happy to film it or provide you with HTML?

On a slow version, can you navigate to about:support (typing it in the url bar), click "copy text to clipboard", and paste it here? That'll attach it to this bug. If you also do it for a fast version it'd be great.

If you have some HTML page that reproduces the issue, yeah, by all means, that'd be super helpful, thanks! :)

Reporter

Comment 5

Reporter

Comment 8

Attachments created.

Can you confirm going to about:config and setting signon.usernameOnlyForm.enabled=false makes it fast again on the original page?

Reporter

Comment 12

Excellent. I can confirm that when I changed signon.usernameOnlyForm.enabled from FALSE to TRUE the table rendered within 3 seconds on the v96 machine.

Reporter

Comment 13

Sorry last post is incorrect. I will correct.

Reporter

Comment 14

When signon.usernameOnlyForm.enabled=false then loads very fast. About 3 seconds.
When signon.usernameOnlyForm.enabled=true then loads very slowly. Over 60 seconds.

This is on the v96 machine. I have tested both settings twice to confirm.

Reporter

Comment 16

My pleasure. Glad I can help.

We should have a limit regarding the maximum number of form we should process (infer whether this is a username-only form) in the password manager.

I don't think this is necessarily about the number of forms... Checking the labels is pretty expensive. Maybe we should make .labels faster at least for connected docs by keeping a list of HTMLLabelElements in DocumentOrShadowRoot, wdyt Olli?

Hmm, tracking all the changes might get a bit hairy, no?
Basically implement nsContentList in a new way, or did you have something else in mind?

Dimi, does the max number for forms work in this case?
The example page has 14498 form elements and 14501 input elements.
Even if we optimized .labels a lot, going through all those elements would take lots of time.

(In reply to Olli Pettay [:smaug] from comment #20)

Hmm, tracking all the changes might get a bit hairy, no?
Basically implement nsContentList in a new way, or did you have something else in mind?

I was thinking of something like what we do for <meta name=color-scheme> here, and yeah, tweaking nsLabelsNodeList to look at that when our owner element is connected so we don't have to iterate over it all. But yeah I hadn't realized that there are 14k forms.

Maybe just not going through them all makes it fast enough. But it's sad that .labels needs to do a full-document traversal :)

(In reply to Olli Pettay [:smaug] from comment #20)

Dimi, does the max number for forms work in this case?
The example page has 14498 form elements and 14501 input elements.
Even if we optimized .labels a lot, going through all those elements would take lots of time.

Yes, reducing form processed while detecting multi-page login form is something I want to do. From telemetry, roughly 90% cases are under 5 forms (here form refers to forms that are possible a login form) per document. Since it's not likely a "login page" contains a lot of forms. I would like to start with setting the threshold to 5 so our heuristic can still cover most of the cases. I guess this optimization and .labels optimization can be done in parallel if we both think they are the right thing to do?

This patch adds a pref "signon.usernameOnlyForm.formThreshold" to limit
the number of form we processed while receiving "PWMGR_NUM_FORM_HAS_POSSIBLE_USERNAME_EVENT_PER_DOC"
event. This improves the performance while loading a page with multiple username-only likely form.

(In reply to Dimi Lee [ooo Jan.29 - Feb.5] from comment #22)

and .labels optimization can be done in parallel if we both think they are the right thing to do?

(It is not clear to me what ".labels optimization" actually would do)