214273 - erstebank.hu - all page content hidden by bad CSS

Status: RESOLVED WORKSFORME

(Tech Evangelism Graveyard :: Other, defect)

Description

[Gábor Ziegler]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; hu-HU; rv:1.4; MultiZilla v1.4.0.4A) Gecko/20030624
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; hu-HU; rv:1.4; MultiZilla v1.4.0.4A) Gecko/20030624

The abovmentioned URL (and many other on the same site) fails to render
completely, if certain styles contains an OWERFLOW:hidden style.

I will attach a test case to prove this

Reproducible: Always

Steps to Reproduce:
1. View the URL :-) You can view only the header-bar of the page
2. Save the page as a complete webpage to local disk (see attachment)
3. Go to the saved stylesheet content_style.css. Find the style declaration for
"#commoncontainerdiv". Comment out the "OVERFLOW: hidden;" style. 
4. open that page from the local disk, now using the modified .css. You can see,
that the main content renders now (altough the layout is ugly).

Actual Results:  
The missing content has appeared

Expected Results:  
I am not a CSS expert at all, but I guess that it should have rendered the main
content visible w/o the CSS hack.

I also guess, that the web-author was lazy, and left the clipping of overflowing
items to the browser. :-(

THE PAGE RENDERS PROPERLY ON NETSCAPE =7.0!!!

Comment 1

[Gábor Ziegler]

Attachment: A sample test page for the bug, see comments about the ncessary CSS hack

Please see the file "Erste Bank_elemei\content_Style.css".
Look for #commoncontainerdiv declration (bears also my inserted comment
 /*mozbug#1*/). 
If you comment out the "OVERFLOW: hidden;" declaration, then Mozilla renders
the main content of the page. If it is not comment out, then just only the
heading figure of the page.

Comment 2

[Gábor Ziegler]

Maybe I should add regression keyword, since Netscape 7.0 renders the page properly?

Comment 3

[Frederic Bezies]

Duplicate of bug 211764 or of bug 197684 ?

Comment 4

[Gábor Ziegler]

As an answer to comment #3, I don't think mine is a duplicate, at least the
symptoms are different. 
Reason:  a.f.a.i.k, bug 211764 is about a hidden object that is not rendered
(which is ok., since it is hidden), but still "occupies screen area"

As for bug 197684 it might be, but I am not convinced. The situation seems to be
similar: an owerflowed object in table, but bug 197684 about rowspan problems,
but in my test case it seems there is no rowspan, or colspan declratation at all...

Being a telecom test engineer, I know that my test case definitely needs some
"distillation", since a bunch of files are far from a minimal, but sufficient
test data, but unfortunatley I am neither a HTML/CSS expert, nor I have enough
spare time for hunting down the problem, I have to admit. I am just a humble
Mozilla fan, who cannot use his brand new(?) internetbanking feature of his
bank... :-(

Comment 5

[Jesiah S]

The problem is that Floated boxes are not considered in the height of block
boxes. http://www.w3.org/TR/REC-CSS2/visudet.html#q17  So the height of
#maincontainer is 0px because it only contains floated boxes.  
#commoncontainerdiv is not tall enough to display #maincontainer so it is
considered overflow and is not displayed b/c of your css.

Comment 6

[Gábor Ziegler]

Being a non-technical (i.e., non-(HTML/CSS-technical)) person for me the comment
#5 is not clear.

It seems the Jesiah S suggests that is not a bug, but a "feature" that follows
from the CSS2 specs. If so, then I think it is a stupid rule that makes possible
for a container that contains only floating objects to render in 0px heigth. 

The page displays "properly" in Netscape 7.0, that is in Mozilla 0.9x, I guess.
The page also displays "properly" in MSIE 6.0. That two browsers makes >90% of
the currently used browsers.  For me, this latter means it SHOULD display
"properly" in Mozilla as well. 

Comment 7

[Mats Palmgren (inactive)]

Attachment: Testcase

Comment 8

[Mats Palmgren (inactive)]

Mozilla is doing the right thing, see comment 5.

-> TE

Comment 9

[Mats Palmgren (inactive)]

Attachment: A suggested fix

Adding <BR clear="all"> after the floats forces the parent to have a height
that wraps the floats.

Comment 10

[Bill Mason]

Confirming new.
Reporter, I would suggesting writing the site owner and asking them to fix the
page.  You could refer them to this bug's URL as a guideline for them.

Comment 11

[Gábor Ziegler]

I will try...

Comment 12

[Mats Palmgren (inactive)]

The URL seems to have been fixed now, right?

Comment 13

[Gábor Ziegler]

Attachment: Screenshot of page fixed as per comment #9 --- rendered by mozilla

Here is the screenshot of the URL rendered by mozilla, after the workaround
suggested by comment #9. The situation is improved significantly (the content
is finally shown), HOWEVER, the background repeated image is still not shown.

Comment 14

[Gábor Ziegler]

Attachment: Screenshot of page fixed as per comment #9 --- rendered by msie

Here is the page rendered by MSIE. 
NOTICE the light-blue color-gradient background that fill the entire
maincontainer div block that encloses the middle (main) content.

Also NOTICE the difference of "marginwidth", that is, the wider vertical space
at the bottom of the main container

Comment 15

[Gábor Ziegler]

Sorry, bad English of mine in comment #14, not "wider vertical space
at the bottom of the main container", but "taller vertical space
at the bottom of the main container"

Comment 16

[Mats Palmgren (inactive)]

The missing vertical space can be fixed by changing the content:

	<p></p>
</div> <!-- End Tag "Home_Div" -->

to:

	<p><br clear="all"></p>
</div> <!-- End Tag "Home_Div" -->

Comment 17

[Mats Palmgren (inactive)]

The only difference in backgrounds I can see is in the right column where IE
displays a light-blue background color, whereas Mozilla have an almost white
bg color.  AFAICT, Mozilla is correct due to this rule in "homepage_style.css":

#rechtercontainer a.xmodultitellink: {
	background-color:#FCFDFE;
	color: #005188
}

Comment 18

[Mats Palmgren (inactive)]

I don't know if trivial matters like these are worth Evangelizing though...

Comment 19

[Mats Palmgren (inactive)]

Site looks fine to me...

-> WORKSFORME

Comment 20

[Gábor Ziegler]

The diffrence is still there, not in the rigth column (right menu pane) but in
the middle column (main content pane).
MSIE renders its background with light-blue, like the righmost pane.

It makes the following situation:
MSIE: renders from left to right
Main menu pane dark blue, a narrow lighter blue separator, and then both the
main pane and the right pane have a more-lighter blue backgroudn

Mozilla renders from left to right
Main menu pane dark blue, a narrow lighter blue separator, and then main pane
with a white(!) background and then the right pane with a more-lighter blue
background

It is indeed small, "aesthetic" difference, and the page is indeed usable, but
nonetheless it could make the page unusable if the background would convey any
semantic meaning

Comment 21

[Mats Palmgren (inactive)]

I think the remaining problem might have actually been a Mozilla bug when
parsing invalid selectors, bug 265542.  Note the trailing ':' in the rule
in comment 17.  The URL is 404 so I can't really tell.

Gábor, please verify with a build dated 2004-11-27 or later.
http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/latest/

-> WORKSFORME

Comment 22

[Gábor Ziegler]

Well, site seems to be heavily redesigned, works even with old mozilla.  (The
developers were extremely responsive on my first bugreport, it might be the case
that they first-handedly tested the new site-design with mozilla.)