From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020728 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 http://www.inforelay.com/colocation.html 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.
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 win2000.
Reproduced (after lots of scrolling up and down) on Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721
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. Notes: 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)
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
OS: Windows 2000 → All
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
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
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 335256
This bug blocks bug 30942 – Browser should remain responsive during most infinite loops
You need to log in before you can comment on or make changes to this bug.