{inc}Wrong page (content) height on first page loading not reflected in scroll bar length




15 years ago
14 years ago


(Reporter: jsixpack, Unassigned)


({qawanted, testcase})

Windows XP
qawanted, testcase

Firefox Tracking Flags

(Not tracked)




(1 attachment)



15 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040106
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040106

The page (content) is rendered too high whenever the page
- is loaded for the first time
- after a forced refresh (shift-reload)
- after a dynamic display:hidden/block change, see below

Reproducible: Always

Steps to Reproduce:
1. load the url http://www.home.nl/nieuws/ (or http://www.home.nl/games/ etc)
2. scroll down to bottom of page
3. the page ends in the (blue) background color
4. press reload (ctrl-R - NOT shift reload)
5. scroll down (if not yet at bottom of page)
6. note a red footer bar, approx. 22 px high

Actual Results:  
As described above; this can be repeated by generating a fresh reload by either
flushing the cache, clicking shift-reload.
Bonus: if you hover the mouse over one of the six "buttons" at the bottom of the
lowest, centered block, the footer moves out of the viewport (if it was visible

Expected Results:  
Always render the footer bar exacly at the viewport bottom if the scrollbar is
scrolled down completely.
Note: this worked up to and including Mozilla 1.5

The pages on this website render in standards compliance mode. 
The characterset is UTF-8.
Layout is completely done with many nested DIV's and styled through an
(external) CSS stylesheet. Some divs are positioned absolute (notably: header
components) or relative. Columns consist of left-floated boxes with fixed width
in some cases. There are no html tables (at least not for the page layout

The "dynamic html" headline browser (the central box with 6 buttons) consist of
positioned boxes, where all but one has "display:none" style. This is
dynamically wrapped by JavaScript on mouseover events on the "buttons".

I have not (yet) been successful in building a reduced test case, will keep
Assignee: general → nobody
Component: DOM → Layout
Keywords: qawanted
QA Contact: ian → core.layout
Summary: Wrong page (content) height on first page loading not reflected in scroll bar length → {inc}Wrong page (content) height on first page loading not reflected in scroll bar length

Comment 1

15 years ago
Created attachment 138611 [details]
Testcase (simplified)

Reduced testcase, see comments (#2) for description

Comment 2

15 years ago
Please use testcase (atachment #138611) for further reference.

The following conditions seem to be necesseary to trigger the observed behaviour:

1. A container block level element (div) with CSS property overflow: hidden
2. A nested block level element (div) with CSS property hight: 100% OR
3. A replaced block level element; the reflow of content out of the page height
takes place as soon as the new dimensions of this element come into effect.

More to point 3:

On the original web portal, the replacs elements are image icons (42x42 px)
which did not have an explicitly set width/height attribute, nor CSS properties.
Setting these from CSS resolves this part of the problem. The image size is only
known after the image is loaded, which causes the reflow event.

However, there's also some "dhtml" feature which works by changing the display
property of divs on the fly. This also triggers the bug.

See the testcase for an example (view source for CSS details).

What I *think* is the basis of this bug is that somehow the render engine
recieves an event that the page layout is complete. Aftet that, dynamic changes
of dimensions of elements should cause a reflow of the layout. If conditions 1
and 2 above are met, this reflow is only partially/incorrectly calculated and
the page not correctly updated.

I fixed the behaviour on the original portal pages (by removing the "overflow:
hidden" attribute of the top-level div element), so use the attachment instead!

Comment 3

15 years ago
I see this on LInux 2004011808

Comment 4

15 years ago
This bug is still present in Moz 1.7 / Gecko/20040616.

Can someone with "official QA status" please look into this? My estimate is that
this bug can be confirmed by simply comparing the test case between Moz 1.5 and
any later build as of Moz 1.6 (and for comparison: MSIE 6.0, Safari 1.2 and so


15 years ago
Keywords: testcase

Comment 5

14 years ago
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051015
Firefox/1.6a1 ID:2005101508

Johannes, this works for me in the latest builds if I'm understanding you right.
Could you test this in 1.5 beta 2 and see if the problem still exists? Thanks.

Comment 6

14 years ago
Checked testcase in FF 1.5b2, bug appears to be gone now.

Full UA string:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051006

Not tested (yet) on other platforms (Mac, Linux).

Comment 7

14 years ago
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051016
Firefox/1.6a1 ID:2005101619

Please reopen if you can reproduce in the latest builds.
Last Resolved: 14 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.