1957692 - Testcase generating N=500 forms and submitting them takes 27s in both parent and content processes,and is 675x slower than Chrome (Part2 of bug 1950901)

Status: NEW

(Toolkit :: Password Manager, defect)

Description

[Mayank Bansal]

Attachment: pswword-management.html

Split off from https://bugzilla.mozilla.org/show_bug.cgi?id=1950901#c1

STR:

1. Open attached testcase
2. N-500, "submit" the forms
3. Nightly: https://share.firefox.dev/43zP7MU (27s)
4. Chrome: https://share.firefox.dev/3CYApEp (40ms)

Gijs from https://bugzilla.mozilla.org/show_bug.cgi?id=1950901#c2

The submission case in comment 1 is very different and to do with password form submission (presumably to work out if we need to offer to save one). Can you split that into its own bug please?

Comment 1

[Mayank Bansal]

Attachment: about:support

Comment 2

[:Gijs (he/him)]

This is from:

_maybeSendFormInteractionMessageContinue [resource://gre/modules/LoginManagerChild.sys.mjs:2339:43]
_maybeSendFormInteractionMessage [resource://gre/modules/LoginManagerChild.sys.mjs:2269:35]
_onFormSubmit [resource://gre/modules/LoginManagerChild.sys.mjs:2228:16]
_onPageNavigation [resource://gre/modules/LoginManagerChild.sys.mjs:2199:20]
#onFormSubmission [resource://gre/modules/LoginManagerChild.sys.mjs:1651:20]
handleEvent [resource://gre/modules/LoginManagerChild.sys.mjs:1459:14]
JSWindowActorProtocol::HandleEvent
EventTarget.dispatchEvent
#dispatchFormSubmissionEvent [resource://gre/actors/FormHandlerChild.sys.mjs:177:31]
processPageNavigation [resource://gre/actors/FormHandlerChild.sys.mjs:157:24]
onNavigationObserved [resource://gre/actors/FormHandlerChild.sys.mjs:208:23]
notifyProcessRootOfNavigation [resource://gre/actors/FormHandlerChild.sys.mjs:412:32]
onStateChange [resource://gre/actors/FormHandlerChild.sys.mjs:369:16]
XPCWrappedJS method call
HTMLFormElement.submit
autoSubmitForms/< [pswword%20management.html:56:61]
forEach [self-hosted:157:22]
autoSubmitForms [pswword%20management.html:55:33]
onclick [pswword%20management.html:0:1]
EventHandlerNonNull

The testcase does seem very artificial in that the time for each form is just 55ms which isn't particularly significant and quite close to Chrome. I wonder if Chrome swallows the other form submissions, as they are all supposed to be POST requests and there can obviously be only 1 actual navigation of the toplevel frame to the result of the POST. But we process all the forms when the submit event happens and that is what is expensive.

Comment 3

[Mayank Bansal]

FWIW, the browser is completely unusable while the testcase is submitting the forms. (not sure if the profile captures this)

Comment 4

[:Gijs (he/him)]

(In reply to Mayank Bansal from comment #3)

FWIW, the browser is completely unusable while the testcase is submitting the forms. (not sure if the profile captures this)

Not really, there's no jank markers in the parent. I suspect (but am not sure how to verify) that each form submission is generating a separate JSWindowActor IPC message, and processing those in the parent fills up the event queue which is going to lead to the unresponsivenes, but each of the messages themselves processes quickly so there's no hang marker. Florian, is there something on file to notice this more clearly (and/or am I just missing something) ?

There is some noise in the profile in the parent due to uBO - can you re-profile without it to compare apples to apples?

Comment 5

[Mayank Bansal]

(In reply to :Gijs (he/him) from comment #4)

There is some noise in the profile in the parent due to uBO - can you re-profile without it to compare apples to apples?

Thats surprising.. the tab with the testcase had uBlock disabled.
Anyway, i reprofiled on a fresh firefox profile.
Here is the prpfile: https://share.firefox.dev/43zP7MU . Also updated comment 0 with it.

---

(In reply to :Gijs (he/him) from comment #4)

Not really, there's no jank markers in the parent. I suspect (but am not sure how to verify) that each form submission is generating a separate JSWindowActor IPC message, and processing those in the parent fills up the event queue which is going to lead to the unresponsivenes, but each of the messages themselves processes quickly so there's no hang marker.

N=100
With IPC marking: https://share.firefox.dev/3Eeg26t

Comment 6

[Mayank Bansal]

Filed bug 1957813 for the (maybe unexpected) Ublock samples.