154230 - No scrollbar appears (involves position:absolute)

Status: VERIFIED FIXED

(Core :: XUL, defect, P1)

Description

[Jeremy Wrinkle]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.1a) Gecko/20020614
Netscape/7.0
BuildID:    2002062308

When you go to http://www.vkacademy.com/ in Mozilla, the page loads fine. But
reloading the page causes the scrollbar to disappear. Using the scrollwhell, and
keyboard shortcuts do not work. Only using the TAB key works, and the page still
does not scroll, but allows you to blindly navigate the page's links. Seems to
affect the whole site.

Reproducible: Always
Steps to Reproduce:
1. Go to site.
2. Reload site, or choose a link, and then go back.

Actual Results:   The page will not scroll.

Expected Results:   The page should scroll like anyother.

Comment 1

[John Morrison]

The page is structured as one big abs. pos. div and a bunch of smaller 
abs. pos. divs, except for the last bit of the page which are two script
The first is an external src, the other inline which executes the code
from the first <script>; this docwrites another (undimensioned)
image into page. 

Removing this last bit of JS from the page seems to "fix" the problem.

So, some oddity with positioned divs and then a final bit of reflow from 
the content appended at the end.

Comment 2

[alanjstr]

Un-maximizing the window restores both scrollbars.  Re-maximizing still has
them.  Reloading makes them dissappear again.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1a) Gecko/20020617

Comment 3

[alanjstr]

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

Comment 4

[Jesse Ruderman]

These pages use also absolute positioning and have no scrollbars:
http://www.geocities.com/jaycee_55/lately.html
http://maps/submit2.cgi?r_loc=27086

I don't have to reload in order to see the bug.  Resizing the window fixes both
pages.  Mozilla build 2002 062408 on WinXP.

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

See also bug 38639.

Comment 6

[Jesse Ruderman]

Attachment: testcase based on jaycee's geocities page

Scrollbar only appears 20% of the time when the page loads, but wheel/keyboard
scrolling works and makes the scrollbar appear.

Comment 7

[Jesse Ruderman]

Attachment: testcase based on maps.mcom.com

At first, scrollbars appear.  A position:relative div moves every half a
second.  The first time it moves, the vertical scrollbar disappears.  The
second time it moves, the horizontal scrollbar disappears.  (Up to this point,
you can reset the clock by scrolling with the mouse wheel.)  The third time it
moves, the mouse wheel stops working permanently.

Comment 8

[HARUNAGA Hirotoshi]

http://bugzilla.mozilla.gr.jp/showattachment.cgi?attach_id=922
another testcase with position:absolute and SCRIPT[src]

Using 2002070108-trunk/Mac OS 9.2, no vertical scrollbar appears.

This SCRIPT SRC URL:
http://oz.valueclick.ne.jp/cycle?banner=a0023996&host=h0011004&c=17&size=468x60&t=js&dart_timestamp=1025590768.8210036&t=js
returns following scripts for example.

document.write('<A
HREF="http://oz.valueclick.ne.jp/redirect?banner=a0024030&host=h0011004&c=17&size=468x60&t=js&dart_timestamp=1025662465.5567916"
 TARGET="_blank"><IMG SRC="http://st.valueclick.ne.jp/ad.s/a0024030.gif"
width="468" height="60" BORDER="0" ALT=""></A>\n');
document.write('<!-- Ad-Reach: valueclick.ne.jp -->\n');

Then putting these scripts in <SCRIPT> content, there is no problem,
without knowing why.
http://bugzilla.mozilla.gr.jp/showattachment.cgi?attach_id=923

Comment 9

[daniel.pz]

I see at least a similar problem on http://www.handelsblatt.com . But only on
subpages, i.e. if you try any link on the main page in order to get a full article.

This bug appears with 1.1a build 2002070908 but not with 1.0RC2.

Comment 10

[Jesse Ruderman]

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

Comment 11

[Ere Maijala (slow)]

Marking OS=All. There are duplicates from Win2k and OS/2 and I see this on WinXP
(trunk 20020720).

Another example: http://www.finnkino.fi/elokuvat/default.asp

Comment 12

[Gérard Talbot]

I think people should know that absolutely positioned elements are taken out of
the normal flow, litterally taken out of the body element and then repositioned
within the document root element. When this is done dynamically, then the normal
page reflow, repaint (because layout is modified) which follows makes the
scrollbar appears. Same thing with a resize event: while resizing, a normal page
reflow is executed and on a mouseup event (see bug 114649), the resize event is
fired triggering any related user-defined code.

The jaycee_55 page has code which won't be executed *_at all_* by Gecko-based
browsers:
document.PageElement.LAYERS['root'].left = Math.max((window.innerWidth - 1000) /
2, 0);
and
history.go(0);
achieve basically nothing, absolutely nothing. The scrollbar appears in
jaycee_55 page on a resize event because the page (content) is simply reflowed,
repainted.

It seems to me (my intuition, hunch) that this scrollbar appearance bug refers
as to when (and where) exactly (on a load event) the size of the document root
element is determined (and then compare) by the code. I.e.: content, width and
height dimensions of root element being compared with the browser's viewport
inner dimensions.

The body element should not and must not be the decisive node to check for a
document's width/height; the document root element (html) should be and must be
the only and decisive node to check for a document's width/height.

I can demonstrate all this with dynamic interactive demo cases.

Comment 13

[Gérard Talbot]

Attachment: Absolutely positioned elements affect the root element dimensions

The fuchsia rectangle is an absolutely positioned paragraph.
The red rectangle represents the body node.
The lime rectangle represents the root node.

The fuchsia rectangle is outside the body node, not just visually but outside
the body containment hierarchy as well. Now, the fuchsia rectangle will be
repositioned every 3 sec. outside the body node but within the bottom edge of
the root node. While doing this, the root node will always stretch toward the
bottom to accomodate the new position of the fuchsia paragraph. In other words,
absolutely positioned elements affect the dimensions (scroll width/height view
and width/height) of a document, therefore, they should affect presence/absence
of scrollbars.

2 other upcoming demo cases will further support/demonstrate all this (both
visually and with real time DHTML values).

Comment 14

[Gérard Talbot]

Attachment: Interactive demo on the effect positioned vs static elements have on DHTML object model properties which are involved into the display of scrollbar(s)

Just play around with this demo: resize the browser, change the screen
resolution, etc..

When you see a blue rectangle within a red border, then you see the body node
with a paragraph.

When you just see the yellow characters on a black background, then the
paragraph is absolutely positioned and is NOT within the body node and the
values displayed via the alert show this. Notice how the passing from absolute
to static and static to absolute affect the display of scrollbar(s). The
paragraph does not change its position at all within the view: its position
within the node hierarchy changes though.

Comment 15

[Gérard Talbot]

Attachment: Demo case highlighting the changing DHTML values during the loading process

Play around this demo: resize the browser, change screen resolution, load,
reload, etc..

Examine carefully the numbers of each alert. Notice that the vertical scrollbar
appears when the document.documentElement.offsetHeight shows a value of 1200
and then disappear after the 2nd alert (and the DHTML values reflect,
correlates this happening).

More tests could be done.

Comment 16

[Dimitrios]

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

Comment 17

[Winnie Lam]

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

Comment 18

[Boris Zbarsky [:bzbarsky]]

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

Comment 19

[Boris Zbarsky [:bzbarsky]]

http://bugzilla.mozilla.org/attachment.cgi?id=92563&action=view is a pretty
clear testcase that shows that an incremental reflow targeted outside the
positioned stuff breaks things....

Comment 20

[coen]

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

Comment 21

[Boris Zbarsky [:bzbarsky]]

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

Comment 22

[Dimitrios]

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

Comment 23

[Dimitrios]

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

Comment 24

[Dimitrios]

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

Comment 25

[Randell Jesup [:jesup] (needinfo me)]

-> karnaze since Attinasi isn't around

cc waterson, dbaron, me

Comment 26

[karnaze (gone)]

Attachment: further reduced test case

Comment 27

[karnaze (gone)]

In "furher reduced test" case, the canvas frame is returning a desired height of 
14550 twips which should force the scroll frame to have a vertical scroll bar, 
but it doesn't show up.  So, this could be a scroll frame or box frame problem. 
-> XP Toolkit/Widgets Trees (for lack of a better fit). 

VP 01AE80BC r=1 a=9180,4470 c=9180,4470 cnt=45
 scroll 01AE836C r=1 a=9180,4470 c=9180,4470 cnt=46
 scroll 01AE836C r=1 a=9180,4470 c=9180,4470 cnt=47
  canvas 01AE80F8 r=1 a=8940,UC c=8940,4230 cnt=48
   area 01AEFC2C r=1 a=8940,UC c=8940,UC cnt=49
    block 01AEFE50 r=1 a=8940,UC c=8700,UC cnt=50
     block 01AF0418 r=1 a=8700,UC c=4500,UC cnt=51
      text 01AF049C r=3 a=4500,UC c=UC,UC cnt=52
      text 01AF049C d=300,285
     block 01AF0418 d=4500,300
    block 01AEFE50 d=8700,300
   area 01AEFC2C d=8940,540
  canvas 01AE80F8 d=8940,4230
  canvas 01AE80F8 r=2 a=9180,UC c=9180,4230 cnt=53
   area 01AEFC2C r=2 a=9180,UC c=9180,UC cnt=54
    text 01AEFD98 r=2 a=9180,UC c=UC,UC cnt=55
    text 01AEFD98 d=0,0
    block 01AEFE50 r=2 a=9180,UC c=8940,UC cnt=56
     text 01AF0034 r=2 a=8940,UC c=UC,UC cnt=57
     text 01AF0034 d=0,0
     place 01AF02EC r=2 a=8940,UC c=UC,UC cnt=58
     place 01AF02EC d=0,0
     text 01AF0324 r=2 a=8940,UC c=UC,UC cnt=59
     text 01AF0324 d=0,0
     block 01AF0418 r=2 a=8940,UC c=4500,UC cnt=60
     block 01AF0418 d=4500,300
    block 01AEFE50 d=8940,300
    area 01AF0188 r=2 a=9180,UC c=UC,UC cnt=61
     text 01AF027C r=2 a=9180,UC c=UC,UC cnt=62
     text 01AF027C d=21990,13290
    area 01AF0188 d=9180,13800
   area 01AEFC2C d=9180,540
  canvas 01AE80F8 d=21990,14550
 scroll 01AE836C d=9180,4470
 scroll 01AE836C d=9180,4470
VP 01AE80BC d=9180,4470
ScrollbarFrame(scrollbar)(-1) 01AE87B8 r=1 a=9180,240 c=9180,240 cnt=63
ScrollbarFrame(scrollbar)(-1) 01AE87B8 d=9180,240

Comment 28

[Christian Schmidt]

Attachment: Test case (1:2)

The problem seems to occur only when the document object is being accessed from
Javascript.

Compare this testcase and the following testcase. The only difference is in the
piece of Javascript.

This testcase generates a vertical scrollbar in about 25% of the reloads. The
next testcase always generates a vertical scrollbar.

I appears to be only the document object that is affected. At least window,
location and history are not.

Using build 2002073108.

Comment 29

[Christian Schmidt]

Attachment: Test case (2:2)

Comment 30

[Gérard Talbot]

Christian, I corroborate your findings regarding attachments 93436 and 93438 in
build 2002072918. It sure looks like that the problem occur only when the
document object is being accessed from Javascript.

Comment 31

[david grogan]

It looks like you have enough examples/test cases already, but it happens here too:
http://sports.espn.go.com/mlb/schedule?team=bal

Using build 2002080204 trunk with win2k.

Comment 32

[David Hyatt]

This has nothing to do with trees.

Comment 33

[Asa Dotzler [:asa]]

I believe that this regressed between 1.0 and 1.1alpha. 

Comment 34

[Boris Zbarsky [:bzbarsky]]

The testcases work in trunk build 2002-06-11-08.  They fail in trunk build
2002-06-13-21.  Some possible culprits in that time span:

roc's changes for bug 124685 (long shot)
dbaron's changes for bug 146831 (my money's on this one)
kin's changes for bug 141900

Comment 35

[Blu3]

This site.. http://www.schroepl.net/projekte/mod_gzip

View, browse, be confused.  Sometimes you can scroll, sometimes you can't.  No
javascript involved, just pos:abs.

Comment 36

[Alfonso Martinez]

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

Comment 37

[kinmoz]

Yeah it's due to bug 146831, the 2nd change in nsBlockFrame.cpp:

-  if (NS_SUCCEEDED(rv) && mAbsoluteContainer.HasAbsoluteFrames()) {
+  // We want to do this under either of two conditions:
+  //  1. If we didn't do the incremental reflow above.
+  //  2. If our size changed.
+  // Even though it's the padding edge that's the containing block, we
+  // can use our rect (the border edge) since if the border style
+  // changed, the reflow would have been targeted at us so we'd satisfy
+  // condition 1.
+  if (NS_SUCCEEDED(rv) &&
+      mAbsoluteContainer.HasAbsoluteFrames() &&
+      (eReflowReason_Incremental != aReflowState.reason ||
+       aReflowState.path->mReflowCommand ||
+       mRect != oldRect)) {

With the test case, the scrollbars fail to show up when an incremental reflow is
dispatched and the AreaFrame (for the html element) which has absolute frames
has the following:


  aReflowState.reason == eReflowReason_Incremental
  aReflowState.path->mReflowCommand == null
  mRect == oldRect

I think that when the scrollbars do show up, it's due to the fact that several
incremental reflows were batched together so the AreaFrame does have a reflow
command targeted at it.

Comment 38

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I'm working on a fix (and one that will provide most of the groundwork we need
to fix bug 75121).

Comment 39

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: patch, v. 1

OK, never mind about groundwork for bug 75121.	I discovered the code to stuff
the overflow area in a frame property in nsAbsoluteContainingBlock.cpp, so I
attached the groundwork that I wrote to bug 75121 instead of here.  That makes
this fix much simpler.	(And it also means that the existing incremental reflow
code is quite efficient.)

A little bit of dead code removal is thrown in for free, since I've had it in
my tree for a while.

This patch is quite simple -- in the case where it doesn't reflow the
absolutely positioned children, we have to recover their overflow areas from
the frame properties that have been stored.  This requires calling a member
function on nsAbsoluteContainingBlock that I had to change from protected to
public.

Comment 40

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: patch, v. 1 (diff -uw; ignoring whitespace changes)

Same as above, but without whitespace changes.	For review, but not testing or
checking in.

Comment 41

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(Apparently we don't have a 1.1-final target milestone.  Aargh.)

Comment 42

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 93804 [details] [diff] [review]
patch, v. 1

r=bzbarsky

Comment 43

[Matthias Versen [:Matti]]

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

Comment 44

[Asa Dotzler [:asa]]

Comment on attachment 93804 [details] [diff] [review]
patch, v. 1

a=asa (on behalf of drivers) for checkin to 1.1 pending sr

Comment 45

[Johnny Stenback (:jst)]

Comment on attachment 93804 [details] [diff] [review]
patch, v. 1

sr=jst

Comment 46

[David G King]

As per Comment #41, I see we do now have a 1.1Final target milestone, so
changing to that to keep things clean. Also, at the moment the Trunk is closed
(for branching I assume), should that preclude this patch from being checked in?

Comment 47

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Fix checked into trunk, 2002-06-08 05:54 PDT.

Comment 48

[Gérard Talbot]

While using build 2002080604 on Windows XP Pro, I tried attachment 93436 [details] .

After 10 times loading/reloading/refreshing the page, the vertical scrollbar
appeared 4 times and did not appear 6 times. So, the problem still seems to be
there. I have another page where I still have problems with scrollbars
disappearing/appearing and this, despite trying with the latest trunk build. The
problem definitively involves absolute positioning (and maybe fixed positioning
as well).

Comment 49

[Boris Zbarsky [:bzbarsky]]

> Fix checked into trunk, 2002-06-08 05:54 PDT.

> While using build 2002080604 (2002-08-06 04:00:00)

You're testing with a build that was built at least 2 hours before he patch was
checked in.  Not useful.

Comment 50

[Gérard Talbot]

I thought the 04 meant the 4th build of the day. On the ftp site, it says 09:15. 

Sigh.. sorry everyone . Really sorry ..

Comment 51

[Matthias Versen [:Matti]]

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

Comment 52

[Gérard Talbot]

I have tried all the testcases filed in this bug file with build 2002080614 in
Windows XP Pro and each of them worked fine. Problem solved! Bravo! I'll do some
more checking as I have other files where absolute positioning is dynamically
involved.

Comment 53

[Matthias Versen [:Matti]]

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

Comment 54

[chris hofmann]

a=chofmann for 1.0.1

Comment 55

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Fix checked in to MOZILLA_1_1_BRANCH, 2002-08-07 12:49 PDT.
Fix checked in to MOZILLA_1_0_BRANCH, 2002-08-08 14:34 PDT.

Comment 56

[Mats Palmgren (inactive)]

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

Comment 57

[Wesha]

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

Comment 58

[Boris Zbarsky [:bzbarsky]]

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

Comment 59

[Matthias Versen [:Matti]]

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

Comment 60

[Dimitrios]

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

Comment 61

[Malcolm Rowe]

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

Comment 62

[Boris Zbarsky [:bzbarsky]]

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

Comment 63

[Michael Lefevre]

testcases all WFM with 2003041009/win2k. no new reports; verified fixed.