Using trunk build 2002061908 on win-xp, 1.1ghz,512ram going to http://wd-test/techlab/things/ makes mozilla nearly hang. works fine in msie6 a profile would be great to see what's going on.

Heavy innerHTML 6 DOM Manipulation: Constructs a big amount of tables and table cells, adds them as innerHTML child elements with inline CSS for absolute positioning to document.body and repeats this, having the document growing all the time. Between every new instance (every addition of a child element), there is a timeout of 1ms. - Works fine on IE from 5.5 up - Works on Moz 1.0 Build 2002052918 @ Linux - Works on Moz 1.0 Build 2002053012 @ Win2k - Works on Moz 1.0 Build 2002061106 @ WinXP - Does NOT work on recent trunk builds!

Confirming that it does not work with trunk build: 2002061708 on WIN2K. Works fine with branch builds: 2002061708.

Most of the time seems to be under nsDrawingSurfaceGTK::Lock and in nsBlender::Do24Blend

to compositor, I guess

Unlikely to be compositor because nothing has changed there for months.

testing trunk build 2002061014 works fine. testing trunk build 2002061208 hangs mozilla. so this seems to be a regression of bug 124685.

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=06%2F10%2F2002+12%3A00%3A00&maxdate=06%2F12%2F2002+08%3A00%3A00&cvsroot=%2Fcvsroot shows also some other 'good' candidates

The URL in the URL field works for me with 202062109-TRUNK. I tried the URL in the report, and got host not found.

wfm on winxp mozilla 1.1a

This totally hangs my Mozilla (build 20020625) on Windows 2000. Just tried it with Netscape 6.2 and it does not hang at all.

In the Win32 debugger it looks like there are a lot of calls to UpdateView() happening which result in calls to nsWindow::Invalidate() ... which basically does an InvalidateRect() on the widget ... this should generate an OS paint event, so it looks like the speed at which we are reflowing and generating the invalidations is causing us to starve paint events which may be sitting in the OS event queue waiting for an idle moment to be processed? No view manager calls are ever made during the reflow or insertion of content that post a paint PLEvent or a synchronous call to Composite(), so it looks like we are at the mercy of event and PLEvent queue priorities? I also put a break point in nsPresShell::Paint() and it never gets hit. The only way I could get things to render/animate was to put a hack in ReflowEvent::HandleEvent() to force a view manager composite.

This is probably a dup of bug 129640

Also when watching the testcase memory consumption is skyrocketing.

URL does not work anymore.

http://www.world-direct.com/mozilla/things/index.html is working fine here!

Nominating for nsbeta1 as this a regression of DHTML performance.

On CVS trunk Linux/GTKfe http://www.world-direct.com/mozilla/things/index.html seems to work okay. It does take about 5 seconds to layout on my 400MHz machine which isn't ideal but neither is that really very hang-y.

I think this problem is affecting mainly Windows users. My Mozilla completely hangs. With build 20020723, Windows 98, Pentium III, 800 Mhz, 512 MB RAM.

I still hang using trunk build 2002072514 on win-xp pro,1.1ghz,512,GeForce2 Go (32ram). but I think kin has done good investigation in comment #11 so he might know how to cope with that

If DOM setTimeout is being used, note that it uses nsITimer's implementation, which on windows runs timers on the main thread only when the main thread's event loop idles. /be

I don't think it's bug 124685. I backed out everything but the widget changes, and it didn't make any difference. I little bit digging shows that no Windows messages are processed at all while the system seems hung. After a while they all come in a tight bunch (this includes region invalidates). Also nsViewManager::UpdateAllViews() is not called until events start to flow. Will need more digging to find out where it all stops. There were some timer and reflow changes too. Maybe they have broken something.

Crap. Disregard my previous comment. I had a major flaw in my tests. I'll do them again.

I think there was one mistake when timer priorities were removed. This timer should have been idle one. Seems to fix the issue for me.

Comment on attachment 93193 [details] [diff] [review] Possible patch to fix a timer idle parameter er, ooops my mistake, sorry about that r=biesi

Comment on attachment 93193 [details] [diff] [review] Possible patch to fix a timer idle parameter Nice catch, Ere! sr=jst

I've requested approval for landing in trunk.

Comment on attachment 93193 [details] [diff] [review] Possible patch to fix a timer idle parameter a=asa (on behalf of drivers) for checkin to 1.1

Fix checked in to trunk.

This fix seems to have fixed the frame drops regressions! Bug 155160 WFM now.