From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0) BuildID: 2000071520 Mozilla is slow when moving nested DIV's - only when the browsers scrollbars are visible. Reproducible: Always Steps to Reproduce: 1. Create an nested DIV with a lot of content clipping it so only a part of it is visible. 2. Use setTimeout to move the nested divs top-position. 3. Change content to something smaller. Actual Results: Less content - faster performance.

Adding perf keyword

Reassigning to layout, there's unneccessary scrollbars on the page and it looks like the reason for those showing up is that the content outside the clipped rect affects the size of the scroll view, thus as the content is moved up, we recalculate and reflow too much... As long as the scrollbars are'n shown we're doing pretty good...

I'm changing this to reflect the problem of a scrollbar being shown when absolutely positioned content is actually clipped and does not require a scrollbar. My (naive) guess is that nsGfxScrollFrameInner::GetScrolledSize needs to account for the clipped size of the frame's view, not the bounds, but these absolute positioning problems are always more complicated than I originally assume. Over to evaughan for further analysis.

Hmm. In current builds, that testcase crashes, and it's quite slow whether scrollbars are showing or not. Has something changed? Marc/Johnny, could one of you have a look. Eric is away on vacation for another couple of weeks. (Nominating nsbeta3; we probably need to fix this html crash at minimum).

It didn't crash for me (my build is from Monday, WinNT) but I am pulling fresh source now...

nsbeta3+

I was getting the crash when I mouseover the anchor in the top left corner (the one that initiates scrolling) -- usually the second (sometimes third) time I did the mouseover.

I'm not getting this crash on either NT 4 or Linux on today's build. Perhaps it went away or is this a Windows 2000 only crash? Also, on the performance issue, I noticed that once we are scrolling, a whopping 100% of CPU time (as reported by the task manager) is being used. When I tried this in IE 5, barley 1% of the CPU was being used and the scrolling was MUCH faster (and no scroll bars). I think I've seen this bug before though. It reminds me of the PR2 default home page slowness. There is also quite a bit of lag from the test site. Attaching a copy of this testcase to bugzilla.

Please file separate bugs for other defects, let's not morph this bug report to cover performance issues. marking as assigned, but if nobody is seeing it, please mark WFM.

reproduced crash in d&d timer code after jumping through many hoops. Seems very obscure, wouldn't hold N6 for this, or for an errant scrollbar. nsbeta3-/future

[nsbeta3-], really this time.

Upon managerial request, adding the "testcase" keyword to 84 open layout bugs that do not have the "testcase" keyword and yet have an attachement with the word "test" in the description field. Apologies for any mistakes.

->moz1.0

build 2001112803 win32 performance in the testcase is beautiful. not sure about the scrollbar, is it really not suppost to be there???

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)

Peter Belesis (author of the famous HierMenus from webreference.com ) is describing some problems in the latest release regarding this. just see: http://www.webreference.com/dhtml/column62/6.html

*** Bug 140892 has been marked as a duplicate of this bug. ***

*** Bug 141264 has been marked as a duplicate of this bug. ***

*** Bug 166696 has been marked as a duplicate of this bug. ***

*** Bug 167647 has been marked as a duplicate of this bug. ***

By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and <http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss bugs are of critical or possibly higher severity. Only changing open bugs to minimize unnecessary spam. Keywords to trigger this would be crash, topcrash, topcrash+, zt4newcrash, dataloss.

*** Bug 155178 has been marked as a duplicate of this bug. ***

*** Bug 135503 has been marked as a duplicate of this bug. ***

.

*** Bug 203598 has been marked as a duplicate of this bug. ***

*** Bug 203598 has been marked as a duplicate of this bug. ***

Guys, Whole point of my findings in BUG #203598 is this is a problem only with absolutely positioned elements. EVERYTHING works fine if child is relatively positioned! Pls. look at my tests for proof.

adt: nsbeta1-

Many DHTM librarys (scrollers & the very famous HierMenus) are encountering this problem. We also do extra painting hence facing performance problems when the scrollbars are appearing. So, having this attacked in the 1.5 timeline would be really a fine thing.

Removing crash keyword, since the testcase does not crash, and if it would then a separate bug would be better.

Will this ever get fixed?

needs a minimized testcase

This is reduced from the previous testcase. The only reason why IE is not showing a vertical scrollbar here is because it supports scroll="no" on the <body>. Otherwise, it would do the same as Mozilla. And afaics, this is correct behavior per spec: http://www.w3.org/TR/CSS21/visufx.html#clipping

I agree. Clipping only affects rendering, it doesn't affect layout. If you want to affect layout, use overflow:hidden.