Too many setTimeouts can hang browser




17 years ago
9 years ago


(Reporter: dgrogan, Unassigned)


({hang, testcase})

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)




(2 attachments)

From Bugzilla Helper:
BuildID:    2002072818

After scrolling down the entire page until the end, the browser hangs.  If this
url is in a tab, trying to switch to another tab hangs the browser.  Minimizing
the browser results in it not being pulled up if clicking on its portion of the
start bar.

Reproducible: Always
Steps to Reproduce:
1. go to
2. scroll down the entire page - very important, it doesn't happen without this
3. minimize the browser
4. attempt to remaximize it

Actual Results:  Nothing, mozilla's portion of the start bar (the icon and
title) becomes pushed in, as if mozilla were focused, but it never comes back up.

Expected Results:  Mozilla to respond and become un-minimized.
WFN 2002072808/win98se
Keywords: hang
I'm the original poster, I didn't give information about my system where the
hang occurs.  P3 550, 128mb ram, Nvidia riva tnt2 model 64 graphics card running
Reproduced (after lots of scrolling up and down) on Mozilla/5.0 (Windows; U;
Severity: normal → critical
Mozilla works just fine for me on this page (I've scrolled up/down and
minimized/maximized Moz five times)

Confirmed on 1.1b (2002072204) on Win2K,  PII-366 (see notes re CPU usage below).

If I pull the scroll bar down to approx. where the 'Mid-level' section of the
chart is visible -- not even to the bottom -- I can duplicate it.

I pull the scroll bar down, CPU usage and page fault rate gradually increase (if
I leave it untouched, it remains in initial condition):

After the page loads, Win2K Task Mgr shows Moz using,
   5-20% of CPU
   ~150 page faults/second

'Mini Data Center' image completely visible at the bottom:
   40-50% CPU
   ~335 page faults/second
(can still minimize/maximize at this point)

'Mid-level' section of price table visible, to the bottom:
   94-98% CPU
   ~650 page faults/second
(Moz unresponsive, have to kill process at this point)
Ever confirmed: true
I'm not seeing this exact behavior with 2002073004 and 2002073104, but now, when
the page is scrolled up and down repeatedly, the browser gets less and less
responsive with each scroll.  There is still definitely something wrong with how
this page is handled.
NTDLL! 778827e8()
KERNEL32! 77e73b5b()
_PR_WaitCondVar(PRThread * 0x010b6700, PRCondVar * 0x010b6590, PRLock *
0x010aff08, unsigned int 67460) line 201 + 23 bytes
PR_WaitCondVar(PRCondVar * 0x010b6590, unsigned int 67460) line 548 + 23 bytes
TimerThread::Run(TimerThread * const 0x010afe20) line 262 + 17 bytes
nsThread::Main(void * 0x010bfc58) line 120 + 26 bytes
_PR_NativeRunThread(void * 0x010b6700) line 433 + 13 bytes
_threadstartex(void * 0x010c43d0) line 212 + 13 bytes
KERNEL32! 77e86523()

-> Stuart (timer..)
Assignee: Matti → pavlov
I still have the behavior in comment #6 with 2002120410 in linux with p4 2200 /
512mb ram / geforce 3.
I just tested this on 1.3final, and the bug is gone.

Either our testcase changed, or Moz is fixed.

Do we mark it fixed or try to find another testcase?
I'm still definitely seeing comment #6 behavior with 1.3 final in linux.  To
trigger it, I grab the scrollbar on the right of the page, scroll up and down
the entire page about 30 times and then watch cpu usage stay at 95%, even after
I stop scrolling.  Scrolling less than 30 times still demonstrates the effect,
just not as much.  I have a geforce3, 2.2 ghz p4, 512 mb.
Using Moz 1.3 final on Win2K.  Trident 3D Cyber9397DVD (laptop).

No bug if I use my scroll *wheel* (IBM Trackpoint on my laptop). I went top to
bottom and back 40 times.  I even tried moving the cursor (press F7 to see it)
to the bottom and back to the top.

I *do* still see the bug dragging the scroll *bar*.  Behavior I see is different
than comment #11 and comment #5.  

  - The first time I drag down the scroll bar to the bottom, CPU usage shoots up
to 70-80%.
  - The page faults are gone (FWIW).
  - Moz still responds after I reach the bottom of the page.

Sorry, I didn't realize the method of scrolling would make a difference.
new test case needed -- the website has changed signifcantly.

I'll leave the bug open since we have some data in comment #7
Product: Browser → Seamonkey
I can confirm this bug (with the current version of the webpage at the supplied
URL) with Linux Firefox (built from a branch pull on 2004/11/25) and on a Linux
Seamonkey nightly.

I am trying to boil it down to a simple testcase, but the problem is buried
somewhere in the middle of a giant piece of obfuscated Javascript.
OS: Windows 2000 → All
Here's a stripped down version of the webpage that only loads the offending
Javascript file "iemenu2.js" from the remote site.  Quickly scrolling down via
the scrollbar will bring the CPU usage up to some constant level (like 30%).  A
rapid up/down scroll will bring it up to 70%, and another will peg it at 100%.

[[Be warned that the Javascript file in question will crash some versions of
multibyte Emacs (specifically, my Debian build of GNU Emacs 21.3.1).  Start
your emacs with "emacs --unibyte" if you want to play with it.]]
Posted file minimal testcase
Here's a minimal testcase.  The problem is that the onscroll handler has been
set to a function f() which reinvokes itself via setTimeout.  Slowly scrolling
the page up and down to generate lots of scroll events will build up a
constant, high CPU usage.
I should add that, once the CPU usage has gotten high enough, Seamonkey stops
responding properly to resize events (if you make the window smaller, the
scrollbars aren't drawn; if you make it bigger, the extra viewport real estate
isn't redrawn properly) while Firefox is worse off---you can no longer select
text in the location bar and the window stops redrawing altogether.

So, I've updated the summary, and I'm going to take a wild guess and refile this
under Core/DOM:Events and reassign it.
Assignee: pavlov → events
Component: General → DOM: Events
Keywords: testcase
Product: Mozilla Application Suite → Core
QA Contact: asa → ian
Summary: browser hangs after scrolling down the entire page → "onscroll" handler that reinvokes itself can hang browser
So basically, opening a lot of timers can hang Mozilla, seems related to bug 261633.
Depends on: 261633
Summary: "onscroll" handler that reinvokes itself can hang browser → Too many setTimeouts can hang browser
Duplicate of this bug: 384131
Blocks: 384325
Blocks: 384323
No longer blocks: 384325
Closed: 11 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 335256
This bug blocks bug 30942 – Browser should remain responsive during most infinite loops
No longer blocks: 384323