bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

Lack of window bgcolor attribute creates flicker



Core Graveyard
18 years ago
6 years ago


(Reporter: bht237, Unassigned)



Windows 95

Firefox Tracking Flags

(Not tracked)



(3 attachments)



18 years ago
This is a bug that all browsers seem to have in common.

Fixing this in Mozilla would with minimal effort create a compelling reason to 
recommend Mozilla to the users of most frame based sites.

When a new window is opened, or when frames are created in a new window,
these windows get a default color (white or gray depending on browser).

The transient state of this window is possibly not subject to any standards
at this stage because most standards describe documents - a window is not a 

But the problem exists because all web applications are subject to network 
delays where an empty window/frame has an ugly color temporarily.

A very unfortunate effect causes this bug to become even worse with faster 
connections and faster processors:


This could be avoided easily if an additional background color parameter could 
be used instead of the white or gray default.

This would not cause any major additional complexity or processing overhead 
because it would just paint the window background in a different color.

And web applications would suddenly look like - any other application,
where flicker would just not be tolerated by users.

Comment 1

18 years ago
You wouldn't mind giving a example URL is describing what to look for would you?
This would require adding support for a non standard attribute/parameter but
given the current stage in the development process I doubt we'd be able to do
anything about this now.

Reassigning to danm, the owner of window related DOM issues...
Assignee: jst → kmcclusk
Component: DOM Level 0 → Compositor
Reassigning to the right person this time, sorry about that...
Assignee: kmcclusk → danm

Comment 4

18 years ago
The problem is probably as old as any GUI. From case to case,
this can be solved by painting a new window while it is hidden and
then showing it.
Unfortunately, things are different in a browser where windows cannot
be hidden while they are constructed.

Imagine using a web application with a black background at night,
full screen.

Then pop up a new full screen window with a network delay of 1/2 second.
The new window will be white for 1/2 second.

This hurts your eyes!.

There is currently nothing you can do about it except document.write()
a matching background before loading content.
But document.write() before loading content causes flicker because you
can't really suppress the initial white, plus it creates history problems
in frames. Believe me I have been through all of this.
I can't really judge the full impact in a live application and give you
a really good test case because of the 37702 blocker.
I thought 37702 would be solved quickly otherwise I would have raised
this one a lot earlier.

Wherever in Mozilla an assumption is made for the background color of a
window or frame before content is available, there should exist a programming
option to override this default.
The override color value should not be changed even intermediately by
anything else except the new document.
This behaviour would allow to completely eliminate flicker.

Comment 5

18 years ago
Created attachment 11402 [details]
test case 1 of 5 files

Comment 6

18 years ago
Created attachment 11403 [details]
testcase file 2 of 5

Comment 7

18 years ago
Created attachment 11404 [details]
testcase zip file, please ignore the others

Comment 8

18 years ago
I am trying to be constructive to get maximum improvement with minimal
effort. The improvement for frame based sites would be dramatic.
There is not much difference between today's browsers.
This change would definitely create a difference ON EXISTING SITES INSTANTLY

Simplified Requirements

1) window.open() needs a bgcolor attribute.
2) <FRAMESET> needs a bgcolor attribute.
3) If a <FRAMESET> bgcolor attribute is not present then <FRAMESET> must
   inherit the bgcolor value from the old document that it replaces:
   3a) This old document could be a plain document.
   3b) This old document could be a frameset.
       If the old frameset does not have a bgcolor attribute then use
       the default color e.g. white.

Minimal Change Impact (1st step) Suggestion

Implement 3) which does not require bgcolor attributes to be settable by
tags for window and frame.

Comment 9

18 years ago
adding RFE and setting status to New
Ever confirmed: true
Summary: Lack of window bgcolor attribute creates flicker → [RFE] Lack of window bgcolor attribute creates flicker

Comment 10

18 years ago
Example of frame flicker visible in Navigator 4, demonstrating that this site is 
confined to a white page background to avoid flicker on change of framesets:

Comment 11

18 years ago
  Interesting idea. There are some problems -- I'm led to believe by people on 
the standardization committees that the features parameter of window.open isn't 
exactly a standard. Yet. But they're moving that way. That was the reason we 
added window.openDialog; to avoid future conflicts with our new features.
  I'm relegating this RFE to the "future" milestone because I know it'll lose out 
against my crasher bugs in the rapidly approaching schedule crunch. I'm also 
(separately) asking for comments from standards body people who've had strong 
opinions about my previous peccadillos with window.open. Barring objections from 
them, I'd consider a patch!
Target Milestone: --- → Future

Comment 12

18 years ago
Another faily obvious and common example shows how much could be gained with
such a trivial change:

Comment 13

18 years ago
Netscape 6 {Build ID 2000092908}
This browser needs this badly. It is the slowest browser I have seen so far and
the frame and window flicker is disgusting.
What a waste of precious Netscape engineering skills, what a poor result.
Don't you really have any better ideas to harvest the benefits of your hard work?
Have you really forgotten the top level component i.e. the window/frame?
You sure know better than me that there is a difference between the document and
the window/frame.
As I wrote before, there is a transient state where, until the document is
loaded, the window is EMPTY and something needs to be done about this.
This embarassing about:blank patch - or whatever is being used to fill this time
gap - really sucks.
With the new version, not ownly the network delays but also the slowness of the
browser contribute to the problem.
Point your browser at http://www.avenue.co.nz and see for yourself.

Comment 14

18 years ago
Bug 24684 covers the same subject with frames. It has a useful testcase for this.
More than ever, I think that Mozilla/Netscape would get a badly needed boost
with this. Currently Mozilla/Netscape is the slowest browser on the market and
new window/frames performance is no exception. This change would not necessarily
speed things up but it would create a new smooth user experience - something
that would definitely set Mozilla apart from all other browsers on the market.
I think that Mozilla is a revolutionary product but it would be nice if this was
more visible to users.
danm, what can be done at this stage? Are you still considering a patch?

Comment 15

18 years ago
  It's been a while for me and this one. Remembering now. Been looking at your 
test case zip file. You've spent a lot of time thinking about this, I see...
  You're proposing adding a new feature to window.open; a feature that sticks a 
permanent bgcolor on a newly opened window so that it will erase itself more 
smoothly; more like a desktop application. (Of course general browser usage 
patterns cause the window to be reused when progressing to a new site; the window 
would want at least to reset its bgcolor when it runs across a bgcolor <body> 
attribute while loading a page.)
  I'm concerned that no one will ever use this window.open feature, limiting its 
practical usefulness. But I guess you have to start somewhere. Well, personally, 
I'm inclined to take a patch if supplied. But I'm not really a standards heavy. 
Let me get some of those guys to weigh in.

Comment 16

18 years ago
Good to hear from you nanm!
"I'm concerned that no one will ever use this window.open feature, limiting its
practical usefulness."
I can't argue with you, based on the present state of the art on the web. The
web still only beginning on its move to become more desktop-like (as you put it
and this is what other people think, too) and this little feature is critical
(for non-Java apps) to get there.
The window.open() part of the proposed change as a whole does actually appear to
have little significance.
But as you put it, "you have to start somewhere". The window.open() is the first
possible event in a chain of flicker flashes that every frame-based application
suffers from today.
I hope that someone will provide a patch, unfortunately I am unable to (not a C
programmer) :( Adding keyword helpwanted :)
Keywords: helpwanted

Comment 17

16 years ago
[RFE] is deprecated in favor of severity: enhancement.  They have the same meaning.
Severity: normal → enhancement


16 years ago
Summary: [RFE] Lack of window bgcolor attribute creates flicker → Lack of window bgcolor attribute creates flicker


13 years ago
Assignee: danm.moz → nobody
Filter on "Nobody_NScomTLD_20080620"
QA Contact: desale → general


9 years ago
Product: Core → Core Graveyard
This seems to be asking for a feature that would have made a lot more sense back in 2000 than it does now.  If there is still something desirable here, please file new bugs for it.
Last Resolved: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.