Closed Bug 59925 Opened 24 years ago Closed 20 years ago

Win initially black, not body bgcolor when body background="img" in effect

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Platform:
x86
All
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
Future

People

(Reporter: david, Unassigned)

Details

(Keywords: testcase)

Attachments

(1 file)

Test case
53.40 KB, application/octet-stream
Details
Current behavior: There is something about the way the underlying HTML--probably the nested table structure plus the cascading style sheet--interacts with the background image that creates an ugly "windowshade" pulling down effect when the browser initially renders the page. The HTML renders perfectly, but the redraw is really ugly. Specifically, even though the cascading style sheet specifies that the body tag should always have a background color of "white", Mozilla initially clears the window to "black", draws all text in their correct foreground colors on the black background, and then redraws the entire page with the background graphic "behind" the text. It's this initial drawing of the page with an incorrect black background that creates the ugly "windowshade" effect. Expected behavior: As the page redraws progressively, it should initially clear the window to the correct background color based on the attributes of the body tag and/or the cascading style sheet. There appears there may be some sort of performance issue here too. Even though the background image is cached after the first page load, subsequent page loads are redrawn just as slowly as the initial page load. Both IE and NN4 display this page faster.
Summary: ugly black "windowshade" effect on redraw → Win initially black, not body bgcolor when body background="img" in effect
--> layout seeing on win98 2000111304. Not sure if this is a bug or not.
Assignee: asa → clayton
Status: UNCONFIRMED → NEW
Component: Browser-General → Layout
Ever confirmed: true
OS: Linux → All
QA Contact: doronr → petersen
I just verified that changing the <body bgcolor="white"... does not alter the behavior. The site is currently relying on the .css file to specify the body background color. It appears that Moz is clearing to black, no matter what the <body bgcolor is or what the css spscifies if there is a background image specified.
Attached file Test case —
That test case gets rid of the cascading style sheet and just uses a <body bgcolor="white" to illustrate the problem. It's a pretty simplefied test case. The file uploaded is named testcase.zip.
Assignee: clayton → harishd
I'm not able to reach the above URL! Btw, is the testcase correct?
I can neither access the above URL nor the testcase. Marking bug INVALID until the problems are resolved ;-)
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
The testcase is a zip file. save it somewhere and use zip-info, stuffit, pkzip, winzip, or whatever you like. rename it .jar and you can use unjar or mozilla.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Thanx
Status: REOPENED → ASSIGNED
Target Milestone: --- → mozilla0.9
This bug has been marked "future" because the original netscape engineer working on this is over-burdened. If you feel this is an error, that you or another known resource will be working on this bug,or if it blocks your work in some way -- please attach your concern to the bug for reconsideration -----
Target Milestone: mozilla0.9 → Future
URL: http://www.coconut-palm-software.com/...
Component: Layout → Parser
Keywords: testcase
This isn't and never has been a parser problem. To layout.
Assignee: harishd → other
Status: ASSIGNED → NEW
Component: Parser → Layout
QA Contact: petersen → ian
This creates a lot of "flicker" as windows & frames constantly reset to black just before loading pages and gives an unprofessional feel to sites and to the browser itself. I would like to see the target for this be better than "Future".
I cannot reproduce with latest trunk builds on Win2k & XP. WFM?
-> WFM
Status: NEW → RESOLVED
Closed: 24 years ago → 20 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: