Note: There are a few cases of duplicates in user autocompletion which are being worked on.

UI hang + Infinite loading + JS Script warning on chromium nightly builds listing

RESOLVED FIXED in mozilla14

Status

()

Core
HTML: Parser
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: Zlip792, Assigned: bz)

Tracking

({hang})

Trunk
mozilla14
Points:
---
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
I am using Firefox Nightly, I always get UI Hang (turning whole Tabs on top area into glass, and loading circle in aero peek and Firefox (Not responding in title)), infinite loading of site and Unresponsive script loading..

Site loading shows Connecting... in tab title once loaded..

Some info:
I tried opening site on clean profile with about:jank addon and got this info:

842 - c-nsEventListenerManager::HandleEventInternal
344 - c-layout::DoReflow
13 - c-layout::FlushPendingNotifications
6 - c-Paint::PresShell::Paint
4 - c-CSS::ProcessRestyles
3 - c-gfx::DrawThebesLayer

Reproducible:
For me always.. while for other on forums.mozillazine.org NO..

Some more info:
Through JavaScript Deobfuscator (development build: 1.6.3a.155), I got enormous call on these script section:

Number of calls: 6348

function getNodeValue(node, tag) {
        return node.getElementsByTagName(tag)[0].firstChild.nodeValue;
    }

Number of calls: 35518

 function alphanumCompare(a, b) {
        var parsedA = splitNum(a);
        var parsedB = splitNum(b);
        var numA = parsedA[0];
        var numB = parsedB[0];
        var strA = parsedA[1];
        var strB = parsedB[1];
        if (isNaN(numA) == false && isNaN(numB) == false) {
            if (numA < numB) {
                return -1;
            }
            if (numA > numB) {
                return 1;
            }
            return strA < strB ? -1 : strA > strB ? 1 : 0;
        }
        if (isNaN(numA) == false) {
            return -1;
        }
        if (isNaN(numB) == false) {
            return 1;
        }
        return a < b ? -1 : a > b ? 1 : 0;
    }

Number of calls: 71036

function splitNum(s) {
        var results = new Array;
        results[0] = "None";
        for (var i = 0; i < s.length; i++) {
            var substr = s.substr(0, i + 1);
            if (isNaN(substr)) {
                results[1] = s.substr(i);
                break;
            } else {
                results[0] = parseFloat(substr);
            }
        }
        return results;
    }

If you need more info regarding anything, I will likely to provide you.
Here is my Nightly info:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20120126 Firefox/12.0a1
C Set: http://hg.mozilla.org/mozilla-central/rev/402b394b6623
(Reporter)

Updated

6 years ago
Keywords: hang
Confirming, setting to NEW

Tested on Win7 x64 latest hourly m-c build:
https://hg.mozilla.org/mozilla-central/rev/206305cbbeb1
Assignee: nobody → general
Status: UNCONFIRMED → NEW
Component: General → JavaScript Engine
Ever confirmed: true
QA Contact: general → general
No problems with the site in IE9, or the latest Chrome Dev version.
From about:jank (plus an xperf run, and the fact that the site has a huge HTML file) it looks like this is mostly layout (though possibly DOM; xperf shows 3% of time in mozjs.dll and 80% in xul.dll).
Assignee: general → nobody
Component: JavaScript Engine → Layout
QA Contact: general → layout
(Reporter)

Comment 4

6 years ago
I tried Gecko Profiler addon from Github (not on clean profile) and got after loading and fully loading (loop is still indicating loading but site loading to be functional for me).. and here is what I got:

Link: http://varium.fantasytalesonline.com/cleopatra/?report=AMIfv97e7YT6nebB8Gkv5By1MQOnDwRSpHC0vQ0Izy0W1lnOOtPp0JnmM0xSQCaPQkxJMqZPXhjGr_gkM7BKs7JEgn2-j-u3luQPjJlT9zHqrdtNb4NG06LSxCRM3lofrCQEdh2k8mnU4XfZ60J_zQrQrMr22s4scQ

Total Samples: 3872

Selection:
--Range: [0,3872]
--Avg. Responsiveness: 1021.88 ms
--Max Responsiveness: 10717.14 ms

3872 (100.00%) Startup::XRE_Main
2376 (61.36%) ??? Unknown
1229 (31.74%) Input::nsInputStreamPump::OnInputStreamReady
195 (5.04%) Timer::Fire
68 (1.76%) event::nsViewManager::DispatchEvent
2 (0.05%) html5::RunFlushLoop
1 (0.03%) layout::FlushPendingNotifications
1 (0.03%) nsEventListenerManager::HandleEventInternal

Maybe of some worth... so posted..
(Assignee)

Comment 5

6 years ago
OK, so...

The "infinite loading" bit is expected: the page does a document.write() after the parser is done, so it opens a new document and never closes it.

For the rest... the page does a half-dozen XHRs to get a bunch of XML.  It parses each one to see whether it needs to get more, then throws the result of the parse away.  Once it has all the XML it goes through, parses all the XML strings _again_, gets data out of the resulting DOMs, sorts it, then document.write()s a bunch of strings out to show some HTML for this, one tiny bit at a time.

I did a quick profile, and the majority of the time seems to be under document.write.  in particular, 65% of the time is spent in nsHtml5OwningUTF16Buffer::AddRef/Release!  Another 25% is spent in various other parser stuff, 

Henri, the refcounting bit looks like the search through those linked lists in Parse() to find the right place in the queue.... why are we hitting the slow case in this situation?  In any case, I'm pretty sure we have a bug on this part.
Component: Layout → HTML: Parser
QA Contact: layout → parser
(In reply to Boris Zbarsky (:bz) from comment #5)
> Henri, the refcounting bit looks like the search through those linked lists
> in Parse() to find the right place in the queue...

The search used to avoid refcounting, but refcounting was added just in case in response to review comments. See 696651 bug comment 17 and other comments in that bug.

> why are we hitting the slow case in this situation?

I haven't debugged this yet, but a reasonable expectation is that the page manages to block the parser and then does many document.writes in little pieces, so it all needs to be buffered up.
(Assignee)

Comment 7

6 years ago
> The search used to avoid refcounting, but refcounting was added just in case in response
> to review comments.

Right; the real problem I see is not the refcounting but the asymptotic characteristics of the algorithm used.

I'm not sure what would block the parser in this case, but can we do anything to make whatever search is going on here faster in common cases (e.g. searching from the end if that would help)?
(Assignee)

Updated

5 years ago
Duplicate of this bug: 744509
(Assignee)

Updated

5 years ago
Duplicate of this bug: 733597
(Assignee)

Comment 10

5 years ago
OK, more details.  Every single Parse() call is coming in with a null aKey.  So we're doing a linear search down to mLastBuffer on each one.  This is silly, imo.
OS: Windows 7 → All
Hardware: x86_64 → All
Summary: UI hang + Infinite loading + JS Script warning on site → UI hang + Infinite loading + JS Script warning on chromium nightly builds listing
Version: 12 Branch → Trunk
(Assignee)

Comment 11

5 years ago
Created attachment 614102 [details] [diff] [review]
When we have a null aKey, don't do a linear search down to mLastBuffer.
(Assignee)

Comment 12

5 years ago
Comment on attachment 614102 [details] [diff] [review]
When we have a null aKey, don't do a linear search down to mLastBuffer.

Henri, is this at all sensible?

Other options include having a prev pointer on these buffer objects or having an mNextToLastBuffer on the parser itself, if you don't think that changing what mLastBuffer points to is acceptable.

This patch _does_ make the page load in fairly finite time.
Attachment #614102 - Flags: feedback?(hsivonen)
Comment on attachment 614102 [details] [diff] [review]
When we have a null aKey, don't do a linear search down to mLastBuffer.

Makes sense. Good observation that firstLevelMarker and the sentinel are same-looking objects.
Attachment #614102 - Flags: feedback?(hsivonen) → feedback+
(Assignee)

Comment 14

5 years ago
Comment on attachment 614102 [details] [diff] [review]
When we have a null aKey, don't do a linear search down to mLastBuffer.

OK, in that case I think we should just get this in.
Attachment #614102 - Flags: review?
Attachment #614102 - Flags: review? → review+
(Assignee)

Comment 15

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/a45e6af2cc32
Assignee: nobody → bzbarsky
Flags: in-testsuite?
Target Milestone: --- → mozilla14

Comment 16

5 years ago
https://hg.mozilla.org/mozilla-central/rev/a45e6af2cc32

Updated

5 years ago
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
This is still not fixed for me, while I don't see the not-responding and pages ghosting out during load, the throbber in the tab still continues to 'run' even though page appears to be fully loaded. 

Win7 X64 latest m-c hourly build which contains the patch:
https://hg.mozilla.org/mozilla-central/rev/e1bef8037d36
(Assignee)

Comment 18

5 years ago
Jim, please read comment 5.
(Assignee)

Comment 19

5 years ago
Sorry, that was a bit abrupt...  The throbber thing is a matter of the page not being done loading from the browser's point of view.  There are other bugs that cover that.

We generally aim for one bug per issue, and the key issue here was the browser hanging.
You need to log in before you can comment on or make changes to this bug.