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

Status: RESOLVED WORKSFORME

Description

[Johannes la Poutre]

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

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

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

Comment 1

[Johannes la Poutre]

Created attachment 138611 [details]
Testcase (simplified)

Reduced testcase, see comments (#2) for description

Comment 2

[Johannes la Poutre]

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
min-height:100%
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

[Jesiah S]

I see this on LInux 2004011808

Comment 4

[Johannes la Poutre]

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

Comment 5

[Adam Guthrie]

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.
http://www.mozilla.org/projects/firefox/

Comment 6

[Johannes la Poutre]

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
Firefox/1.4.1

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

Comment 7

[Adam Guthrie]

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.