Closed Bug 81997 Opened 25 years ago Closed 22 years ago

Changing CSS visibility with DOM causes some visibility problems.

Categories

(Core :: DOM: CSS Object Model, defect)

defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: mgalli, Unassigned)

References

()

Details

(Keywords: regression)

Please go to URL. Tested with 2001051704 and another today build. Win98 but I believe this is also happening with other platforms/os... -- the testcase: it's a gif image (logo) (visibility:hidden initial state) with another png image (white) in the foreground. -- what's expected? When the document is loaded, the logo image is hidden then the foreground image (png) is placed and you can't see the logo image. The onload event calls the go JS function that sets the visibility of the logo image to "visible"... So, in a perfect world, you still can't see the image because it's behind the white png. -- What's happening here... please doublecheck.. I can see the logo image, during some time (less than 1 second)... Seems like we can see this logo image, exactly in the time I did the call document.getElementById('image').style.visibility="visible";..... It's not happening in Netscape 6.0x ..
Need help to confirm... marking regression... Note: the problem happen in the first time. After this, you need do start the browser again to see the problem.
Keywords: regression
Adding a new testcase: This new testcase, the foreground image have white background... not a png image...seems like this is working.... :-/ http://geckonnection.com/test-features/visibility/test2.html
Adding new test: http://geckonnection.com/test-features/visibility/test3.html The png image is not in the background-image.. is inside the DIV. This case works too.
Adding z-index: 5; to the style for the logo makes it show up, I don't think this is a bug, it's probably a bug in Netscape 6.0 that made this work. None of the testcases in this bug works for me, btw.
Johnny, Maybe I was not so clear... the right behavior is to not display nothing.. adding roger,.. cc.. Roger, can you reproduce this?
Oh.
Ah, it looks like we're not waiting for images specified in CSS background-image declarations before firing onload for the document. That would explain the behavior: document starts to load -> body and its descendants start to load -> all descendants (html markup and logo.gif) load -> onload event for <body> fires, n6logo is made visible -> fadevert4.png (specified in style attr) finishes loading, finally displaying and covering up the N6 logo. Unsure as to whether this is correct behavior or not. I'm inclined to say that it is, because: The background-image specified through style is not actually a descendant of the <body> element (it's a property of the View (?)correct me if I'm wrong), so in that sense <body> is actually being fully loaded before firing onload. Thoughts from the gurus? --J
Status: UNCONFIRMED → NEW
Ever confirmed: true
Post-mozilla1.0, unless someone can convince us we must fix this for mozilla1.0.
Hardware: PC → All
Target Milestone: --- → mozilla1.1
Assuming it really is a bug, that is. Ian, any thoughts?
This is happening with me. I am redesigning our company's intranet and I've run across this. I'm using the following code to view a <div>: document.getElementById("div").style.visibility = "visible"; This works in NN6.0 but NOT in NN6.1 OR NN6.2.1 (most recent version was downloaded and installed 2002-03-05 at 1pm)
I could reproduce this once. Only once. Which leads me to suspect that this isn't a bug, it's just the image loading...
Check out http://geckonnection.com/test-features/visibility/test3.html The png file is not shown. See Page Info / Media. The png is visible in IE
Target Milestone: mozilla1.1alpha → ---
Mass-reassigning bugs to dom_bugs@netscape.com
Assignee: jst → dom_bugs
Depends on: latebg
Yeah, this is invalid. As long as background images don't block onload (which they should not), it will be possible to write a testcase like this where a background image load races with onload.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.