45597 - Scrollbars are appearing when not needed when clipped content is present

Status: RESOLVED INVALID

(Core :: Layout: Positioned, defect, P2)

Description

[Magnus Mellin]

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.

Comment 1

[leger]

Adding perf keyword

Comment 2

[Johnny Stenback (:jst)]

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...

Comment 3

[Marc Attinasi]

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.

Comment 4

[John Morrison]

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).

Comment 5

[Marc Attinasi]

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

Comment 6

[Peter Trudelle]

nsbeta3+

Comment 7

[John Morrison]

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.

Comment 8

[Peter Lubczynski]

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. 

Comment 9

[Peter Lubczynski]

Attachment: testcase from site URL

Comment 10

[Peter Trudelle]

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.

Comment 11

[Peter Trudelle]

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

Comment 12

[Peter Trudelle]

[nsbeta3-], really this time.

Comment 13

[Hixie (not reading bugmail)]

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.

Comment 14

[Peter Trudelle]

->moz1.0

Comment 15

[basic]

build 2001112803 win32

performance in the testcase is beautiful.

not sure about the scrollbar, is it really not suppost to be there???

Comment 16

[Asa Dotzler [:asa]]

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)

Comment 17

[Markus Hübner]

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

Comment 18

[Moied]

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

Comment 19

[Boris Zbarsky [:bzbarsky]]

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

Comment 20

[Boris Zbarsky [:bzbarsky]]

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

Comment 21

[Boris Zbarsky [:bzbarsky]]

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

Comment 22

[Brant Gurganus]

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.

Comment 23

[Boris Zbarsky [:bzbarsky]]

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

Comment 24

[Boris Zbarsky [:bzbarsky]]

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

Comment 25

[Boris Zbarsky [:bzbarsky]]

.

Comment 26

[Boris Zbarsky [:bzbarsky]]

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

Comment 27

[Boris Zbarsky [:bzbarsky]]

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

Comment 28

[David]

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.

Comment 29

[Samir Gehani]

adt: nsbeta1-

Comment 30

[Markus Hübner]

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.

Comment 31

[José Jeria]

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

Comment 32

[nick]

Will this ever get fixed?

Comment 33

[Robert O'Callahan (:roc) (email my personal email if necessary)]

needs a minimized testcase

Comment 34

[Martijn Wargers (dead)]

Attachment: 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

Comment 35

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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