1456843 - HTML loading hangs for minutes while updating DOM

Status: RESOLVED FIXED

(Toolkit :: Form Manager, defect, P2)

Description

[brd]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0
Build ID: 20180423171039

Steps to reproduce:

On my site I have a page which contains a <table> with data and custom modal window for every row. While trying to load it in Firefox hangs for minutes while seemingly doing nothing (I tried to attach performance profile below but it is too large for bugzilla to handle (14MB))

I have the whole page saved as one file, which reproduces the problem, but I can't share it as it is because it contains user data. I could prepare a test case by editing the file if it is absolutely needed

The problem is reproducible on both stable and beta branches of Quantum for me, on existing and new profiles, private windows and so on.


Actual results:

Performance profiler shows that while loading in DOM changes Firefox randomly stops it and hangs for minutes, does some garbage collection and continues after a very long delay


Expected results:

Chrome does the full load of the same page in 28s, Edge does it in 35.

Comment 1

[brd]

I've uploaded the Performance profile.json and a test HTML to Google Drive as Bugzilla won't let me do so here

https://drive.google.com/open?id=13XUUSbuKHqAQpNaYnCXz4JLCJ8vBySI0
https://drive.google.com/open?id=11fPmsZeFb7MWf_gFgsQ3Y1p0n6S1_9RK

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

Do you think you could just share the performance profile using the Share button of the https://perf-html.io/ addon?

Comment 3

[brd]

(In reply to Olli Pettay [:smaug] from comment #2)
> Do you think you could just share the performance profile using the Share
> button of the https://perf-html.io/ addon?

Here you go
https://perfht.ml/2HrOj3S

Shows huge processing delays corresponding to Content thread

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

Thanks. FormLikeFactory.jsm is doing something bad.

Comment 5

[Bas Schouten (:bas.schouten)]

Since this profile does not seem to capture what the JS code is doing very well (the samples appear as self time large), I profiled this using VTune and the following stack appeared:

Callees	CPU Time: Total	Effective Time	Spin Time	Overhead Time
resource://gre/modules/FormLikeFactory::jsm:63:18	100.0%	1.295s	0s	0s
  mozilla::dom::binding_detail::GenericMethod<struct mozilla::dom::binding_detail::NormalThisPolicy,struct mozilla::dom::binding_detail::ThrowExceptions>	79.8%	0.001s	0s	0s
    mozilla::dom::ElementBinding::querySelectorAll	79.5%	0.007s	0s	0s
      nsINode::QuerySelectorAll	78.7%	0s	0s	0s
        Servo_SelectorList_QueryAll	78.6%	0.005s	0s	0s
          style::dom_apis::query_selector_slow<style::gecko::wrapper::GeckoElement,style::dom_apis::QueryAll>	69.1%	10.900s	0s	0s
            selectors::matching::matches_complex_selector_internal<style::gecko::wrapper::GeckoElement,closure>	16.9%	3.605s	0s	0s
            style::dom_apis::{{impl}}::append_element<style::gecko::wrapper::GeckoElement>	1.1%	0.124s	0s	0s
          Gecko_ContentList_AppendAll	9.2%	0.018s	0s	0s
          selectors::matching::matches_complex_selector_internal<style::gecko::wrapper::GeckoElement,closure>	0.1%	0.028s	0s	0s
          HeapFree	0.1%	0s	0s	0s
          GetProcessHeap	0.0%	0.008s	0s	0s
          core::ptr::drop_in_place<selectors::nth_index_cache::NthIndexCache>	0.0%	0.007s	0s	0s
        nsINode::ParseSelectorList	0.0%	0.003s	0s	0s
        nsSimpleContentList::nsSimpleContentList	0.0%	0.002s	0s	0s
        moz_xmalloc	0.0%	0s	0s	0s
      nsCachableElementsByNameNodeList::WrapObject	0.5%	0.002s	0s	0s
      JS_WrapValue	0.3%	0s	0s	0s
    [Unknown stack frame(s)]	0.3%	0s	0s	0s
  intrinsic_IsPossiblyWrappedTypedArray	13.4%	0.132s	0s	0s

It should also be noted there was a lot of activity on the Timer Thread and the Main Thread. I wonder if exception unwinding is somehow causing a lot of communication between the processes.

Comment 6

[Bas Schouten (:bas.schouten)]

The timer and main thread activity was explained by a mistaken configuration for me locally, the above stack is still valid.

Comment 7

[Bas Schouten (:bas.schouten)]

Here's a better profile with the gecko profiler.

https://perfht.ml/2I4vJOx

Comment 8

[Mike Conley (:mconley) (:⚙️)]

This seems pretty bad. Looks like we have something kinda like O(n^2) here - for each password input added, we enter this block:

https://searchfox.org/mozilla-central/rev/39b790b29543a4718d876d8ca3fd179d82fc24f7/toolkit/modules/FormLikeFactory.jsm#77-83

and do a querySelectorAll on every input / select on the document. I think the idea is that for the FormLike to be associated with all of the other <form>-less inputs on the page.

At the very least, perhaps the elements list can be computed lazily (if it needs to even be calculated at all).

Comment 9

[Mike Conley (:mconley) (:⚙️)]

Computing the elements lazily seems to fix the test case, and seems pretty simple to do. I'll have a patch up shortly.

Comment 10

[Mike Conley (:mconley) (:⚙️)]

Attachment: Bug 1456843 - Compute FormLike elements lazily on <form>-less fields.

Review commit: https://reviewboard.mozilla.org/r/256872/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/256872/

Comment 11

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 8991976 [details]
Bug 1456843 - Compute FormLike elements lazily on <form>-less fields.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/256872/diff/1-2/

Comment 12

[Matthew N. [:MattN]]

Comment on attachment 8991976 [details]
Bug 1456843 - Compute FormLike elements lazily on <form>-less fields.

https://reviewboard.mozilla.org/r/256872/#review263786

Thanks!

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/78111274557c
Compute FormLike elements lazily on <form>-less fields. r=MattN

Comment 14

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/78111274557c