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)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: jsixpack, Unassigned)

References

()

Details

(Keywords: qawanted, testcase)

Attachments

(1 file)

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...
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
Attached file Testcase (simplified)
Reduced testcase, see comments (#2) for description
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!
I see this on LInux 2004011808
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...).
Keywords: testcase
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/
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).
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.

Attachment

General

Created:
Updated:
Size: