366849 - javascript warnings can busywait cpu and lock all Firefox windows for long periods (25-45s)

Status: RESOLVED INCOMPLETE

(Core :: General, defect)

Description

[L A Walsh]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1

The tvguide page locks up firefox while it is trying to render.
It takes 20-30 seconds to render the tvguide page (using zip=95060, scotts valley comcast cable).  While it is _trying_ to render, Top-menu options are locked-out and the UI is frozen in all FF windows for ~20 seconds.

Part of the lockup is that the UI and/or rendering thread is cpu bound.  
I show 25% of my machines CPU time being used -- which corresponds to 1 core.

I have 4 cores (2chipsx2cores ea), with 4MB cache/core, all running at
2GHz (total of 3GB memory -- max available under WinXP-SP2).

IE takes about 7 seconds to display the page (with no UI lockup or pegged CPU).
Opera takes about 5 seconds to display (also w/no UI lockup or pegged CPU).


Reproducible: Always

Steps to Reproduce:
1.
2.
3.



Oddly, I have a "vague" (unmeasured) perception that it has slowed down with the last ".1") release, but it was slow before that as well -- it may be I'm just tired of FF locking up for 15-20 seconds anytime I refresh the tvguide page and I am "perceiving" the load as taking longer (of course could be different levels of caffeine, but I don't think that's changed so much in a constant way...:-)).

Comment 1

[Giorgio Maone [:ma1]]

I can reproduce it in my extensions-laden default profile, but it doesn't happen at all on a clean profile.
Hence resolving as invalid, as most likely tied to one or more extensions.
Just for the records, could you please follow the steps outlined in http://kb.mozillazine.org/Standard_diagnostic_-_Firefox#Extension_issues and post here your results? Thanks!

Comment 2

[SheeEttin]

I hear that it's caused by Adblock removing ads from the page before it loads. If you have ads blocked on the TV guide page, try setting Adblock to hide ads, rather than remove them, and see if this decreases/eliminates the delay. 

(Also, do you have the "nglayout.initialpaint.delay" setting set? If you do, plase post the value.)

Comment 3

[SheeEttin]

Just tried it--it may also be related to large amounts of JavaScript scripts running.

Comment 4

[L A Walsh]

Hi all,
   I don't believe it is "great form" to close a bug without giving me a _chance_ to reproduce it with extensions turned off, since as in this case, there may be other factors to reproducing this bug that the "closer" did not reproduce.
  2) There is some other factor going on with this bug that hasn't been isolated/duplicated. I just tried accessing the website in safemode, but misspelled the switch as as "-safemode" (vs. -safe-mode) BUT, the website displayed with NO DELAY.  
   >>>This would indicate that it is not the extensions that are causing the problem.<<<  (?what is?, not sure at this point)
   FWIW, I relaunched FF correctly spelling the switch and it still worked...:-)
   FYI, "nglayout.initialpaint.delay" has a value of "0" which appears to be the default(?).

  First thing that comes to mind as a substantial difference: I usually have at least 1 Firefox Window, "active", all the times.  So it may have something to do with having FF up for long periods...but...not so sure.
  The only other possibility I can think of (that makes sense) is that the delay might have to do with some difference in the time-based content on that webpage.

   I'm leaning toward the first explanation -- something about having it up for some time.  The only way I can ... well poo!  I was going to say that the only way to duplicate would be to wait until the bug reappears then try it with extensions off, but that won't work as there is no way to disable extensions without restarting -- thus reinitializing the "problem" and making it go away again.

   I'm not using "Adblock", BTW.  I am using "noscript", but I have script options (and cookies) allowed for this website (otherwise much of it would not work) -- like "hover" events to display program summaries.

    At this point, not sure how to proceed.  I'm not sure "how safe" I'd feel about leaving FF up for long periods with no extensions (like "noscript") active.  Any ideas? 

   My guess was it had something to do with the large amount of javascripts on the page.  It is one of the more complex pages I display (actually, I can't think of any that are more complex, off hand, especially not so frequently as...) almost every day, but was only guessing this from the CPU usage.

   I don't have any extensions loaded (and that would be active on this page) that use cpu time while rendering.

   Giorgio -- could you retest your "extension-laden default profile" after a "restart"?  I'm not sure if that is the difference, but in my case, the act of "restarting" (with or without extensions) makes the bug go away temporarily.

   In the time it took me to write this, the bug has reappeared.  FWIW, I had the page "open", and simply hit reload.  Will try to play some more to see if I can narrow it down any further, but turning off extensions is pointless if I can get the page to load properly, with my extensions enabled, after a fresh restart.  :-(

Comment 5

[SheeEttin]

When I tried it, there was a noticeable delay. I experience the same thing e.g. when logging in to Wikipedia, and there's a lot of JS applied when I log in.

Try setting nglayout.initialpaint.delay to 200 and loading the page. This may or may not affect the loading of the page.

When you say that it goes away when you cold-start Firefox with extensions, it suggests that it may have something to do with caching or memory. Try (after running Firefox for a bit) clearing your cache and immediately reloading the page.

Comment 6

[L A Walsh]

I'm having problems narrowing this down.

I can list some items that seem to be necessary steps, but they are not _sufficient_ to reproduce the bug.

FWIW - I tried 200 with the "Fasterfox" value of "nglayout.initialpaint.delay, that made no difference.

I also believe I have found a _similar_ or related way of duplicating the problem.

You can duplicate the mono-threaded, all windows lock-up behavior by installing the Web-Developer extension.  Go to the extension's options, and to the its "Miscellaneous" panel.  On there select "strict Javascript warnings" and select the options to open the javascript console on warnings and errors -- I believe it is primarily warnings that are causing the most problems.

Then I go to the www.tvguide.com/listings web page (which, happens to, at this instance, to be giving a "file not found error" :-/ ).  When displaying my local schedule, approximately 250 warnings are generated by the "strict" option.

The UI lockup is more severe with the javascript console open, but for whatever reason, about 200 of those warnings are generated during the lockup, which according to my web-logs, takes 25-45 seconds.  The generation of the warning messages shouldn't be taking .1-.2 seconds/message...should it?

Now back to the "hard to duplicate" case -- which appears related -- I go back to the web-dev-options-misc and turn off the "open javascript console on warnings/errors" options.  The "strict javascript warnings", however is still turned on.

In this state, after a cold-start of FF, I encounter no delay.  If I then go turn on the "open JS console on warnings" option and generate a warning -- I see the 200-250 errors that were generated on the tvguide listing page -- but in this instance, they  don't cause a delay (what I would call "correct" or "desired" behavior).

Generating the "bad" behavior is now where the problem is getting "evasive".
Several times, I was able to open only a few other pages (went down a local list of URL's -- each opening in another window -- slashdot, wired, nytimes.com), then opening another window with tvguide in it.  Sometimes that alone would cause the problem to appear.   Other times, I had to open several such sites.

Another weirdness -- _sometimes_ if I closed all the other open pages, a "refresh" on the tvguide site would have the problem -- and occasionally, not.

Problem summary:

For some unknown reason -- when a page generates a large number of javascript console warnings -- the browswer can become cpu bound.  It doesn't always happen.  It is more likely to happen with more pages open and the longer the browser remains up.  I have a local cache size of 0 on disk, so clearing it has no effect.  I'm not close to running out of memory (have 4G phys, 3G seen by Windows, allowing up to 2G/process).  I was able to force cpu bound (I have two 2GHz x 2-Core processors) behavior by turning on the option to open the JS console on warnings.

Second part of the problem (which is the real part that bothers me) -- is that when this happens -- all FF windows, widgets, painting, etc -- is disabled while the cpu is spinning -- as though the cpu is busy waiting somewhere and not listening for GUI events.  This is significantly more disturbing when I see that I have 75% cpu idle (representing 3 idle processors).  Maybe each FF window needs its own process with some shared-memory area used to coordinate processes?
Ideally, each thread could run independently -- if one thread busy waits, the other threads could continue execution on any other processor.  For whatever reason, Firefox is limiting itself to 1 processor, which is really becoming "a bad thing" with the increasing adoption of multi-core machines.

Comment 7

[Wladimir Palant]

I cannot reproduce this with Adblock Plus, and generally this page doesn't have all too many images. So if this really is an extension issue it must be something else.

Comment 8

[SheeEttin]

I'm going to guess it has something to do with bad JavaScript--whether it's error handling, error logging, or what, I couldn't say. I'm not at all familiar with Firefox's handling of JavaScript, nor with JavaScript itself.

Comment 9

[Wayne Mery (:wsmwk)]

I can't reproduce/WFM

but surely http://www.tvguide.com/listings/ of today bears no resemblance to what existed 4 years ago. incomplete without a testcase