610240 - JS hangs browser for about 30 seconds on this page

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Matthias Bockelkamp]

When opening this page, the browser stops reacting for about 30 seconds. Playing with AddBlock Plus shows, that the below named js file causes this behaviour:

http://stg.odnoklassniki.ru/web/gwt/bbf288f7/one.app.community.dk.gwt.dm.block.Block/C0107A329062753D4DBC96991956F8CB.cache.js

Comment 1

[Boris Zbarsky [:bzbarsky]]

I can't reproduce the problem... I load the page, and past being on a slow pipe it seems to be fine.

Matthias, what exact browser build are you using?  Is this a clean profile?

Comment 2

[Matthias Bockelkamp]

I saw this with Firefox 3.6.12, Firefox 4.0b6 and Seamonkey 2.1b2pre. On Firefox 4.0b6 I tried with a clean profile. You can see the spinning sign on the tab stop spinning while the page is loading. During this time Firefox doesn't react to anything. Activating another window and then Firefox again shows that the whole Firefox window doesn't get redrawn.

But there is a change relative to yesterday when I filed this bug: The hang now only lasts for about 7 seconds. So this might be dependent on how busy the server or the network in russia is during the page load.

Comment 3

[Boris Zbarsky [:bzbarsky]]

I suppose... I still haven't been able to reproduce this.

Comment 4

[Matthias Bockelkamp]

Attachment: Testcase

Testcase to show that bug is independent of network delays

Comment 5

[Boris Zbarsky [:bzbarsky]]

Matthias, thanks!  With the attached testcase I can reproduce a 3-second hang or so.  

A profile of the whole pageload shows that about 95% of the time is under JS_EvaluateUCScriptForPrincipals, breaking down as:

  38% under js::Parser::statement (about half in JSFunction::lookupLocal called
      from BindVarOrConst, and about 1/3 under functionDef; half of _that_ is
      lookupLocal again(!).)
  30% UnlinkFunctionBoxes (bug 501908).
  26% under js_EmitTree; almost all of this is js_EmitFunctionScript calling
      js_EmitTree again calling lookupLocal. 

Overall, 51% of the testcase time is lookupLocal self time and 30% is UnlinkFunctionBoxes self time.  5% is setFunctionKinds self time.

Looking at the actual JS files involved, it's basically 1.5MB of:

 function() {
   function AM(){}
   function RM(){}
   function eN(){}
   function nN(){}

etc.  One outer function with a huge slew of functions inside it.

The fact that lookupLocal falls into a linear search in this case is bug 610370.

Comment 6

[Boris Zbarsky [:bzbarsky]]

OK, the patch I just posted in bug 610370 cuts the load time by half or so, as expected.  We should fix bug 501908, then remeasure.

Comment 8

[Robert Lee]

Firefox 4.0 and 5.0:

This happens on the Hotmail compose page consistently. The page initializes using some pretty heavy JavaScript. Just log into Hotmail and click "New" at the top of the inbox and enjoy exactly 30 seconds of "(Not Responding)", even on new profiles and with all plugins disabled.

Also tested the ExtJS demo page with these (new profile, all plugins disabled), and it also hangs for approximately 30 seconds on page load 100% of the time on all the machines I've tested on. I even see it on the Firefox start page (the one hosted by Google).

I'm assuming that there is a specific operation that these pages are doing that is causing recent versions of Firefox to freeze. Perhaps a specific type of DOM manipulation or a specific AJAX use case.

Tested on Windows 7 64bit under Firefox 4.0 and 5.0, and Windows XP 64bit under Firefox 4.0, Windows Vista 64bit Firefox 4.0, Windows Vista 32bit Firefox 4.0, Windows XP 32bit Firefox 4,0 and 5.0.

I've tested on 3 models of HP laptops, 7 models of Dell laptops, 1 Dell workstation, and a variety of Windows VMs running under VMWare workstation, VMWare server, ESX, and LabManager. It is 100% reproduceable using both Firefox 4.0 and 5.0 on a variety of pages.

Comment 9

[Guilherme Lima]

I think this is fixed. (Using Firefox 9.0.1)

Comment 10

[Matthias Bockelkamp]

Yes, it was fixed by depending bug.