Closed
Bug 230193
Opened 22 years ago
Closed 20 years ago
{inc}Wrong page (content) height on first page loading not reflected in scroll bar length
Categories
(Core :: Layout, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: jsixpack, Unassigned)
References
()
Details
(Keywords: qawanted, testcase)
Attachments
(1 file)
2.04 KB,
text/html
|
Details |
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...
![]() |
||
Updated•22 years ago
|
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
Reporter | ||
Comment 1•21 years ago
|
||
Reduced testcase, see comments (#2) for description
Reporter | ||
Comment 2•21 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
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!
Reporter | ||
Comment 4•21 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
on...).
Comment 5•20 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.
http://www.mozilla.org/projects/firefox/
Reporter | ||
Comment 6•20 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
Firefox/1.4.1
Not tested (yet) on other platforms (Mac, Linux).
Comment 7•20 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.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•