45363 - Lack of window bgcolor attribute creates flicker

Status: RESOLVED WONTFIX

(Core Graveyard :: GFX, enhancement, P3)

Description

[bht237]

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 
document.

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:

Flicker

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

[jlarsen]

You wouldn't mind giving a example URL is describing what to look for would you?

Comment 2

[Johnny Stenback (:jst)]

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...

Comment 3

[Johnny Stenback (:jst)]

Reassigning to the right person this time, sorry about that...

Comment 4

[bht237]

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

[bht237]

Attachment: test case 1 of 5 files

Comment 6

[bht237]

Attachment: testcase file 2 of 5

Comment 7

[bht237]

Attachment: testcase zip file, please ignore the others

Comment 8

[bht237]

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
WITHOUT ANY CODE CHANGES.


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

[Asa Dotzler [:asa]]

adding RFE and setting status to New

Comment 10

[bht237]

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:
http://www.wella.com/

Comment 11

[Dan M]

  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!

Comment 12

[bht237]

Another faily obvious and common example shows how much could be gained with
such a trivial change:
http://www.avenue.co.nz

Comment 13

[bht237]

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

[bht237]

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

[Dan M]

  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

[bht237]

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 :)

Comment 17

[Brant Gurganus]

[RFE] is deprecated in favor of severity: enhancement.  They have the same meaning.

Comment 18

[Serge Gautherie (:sgautherie)]

Filter on "Nobody_NScomTLD_20080620"

Comment 19

[Zack Weinberg (:zwol)]

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.