Closed
Bug 24684
Opened 25 years ago
Closed 21 years ago
Document background color is not inherited down the frames hierarchy
Categories
(Core :: Layout: Images, Video, and HTML Frames, defect, P3)
Core
Layout: Images, Video, and HTML Frames
Tracking
()
RESOLVED
WORKSFORME
Future
People
(Reporter: bht237, Assigned: john)
Details
(4 keywords)
Attachments
(4 files)
This collection of HTML files demonstrates a misbehaviour of all Navigator
browsers: The document background color is not inherited down a frame
hierarchy.
This results in very ugly flicker in frame based applications which only
gets worse with faster processors/video cards.
The flicker problem results from the fact that either a gray or white background
is painted over the whole window area before the frameset is built up.
The new window area should be painted in the color of the parent document
instead.
The effect of the test example is mild compared with more complex frame
sets:
This IS a serious problem for new generation web sites:
Some documents loaded into frames contain embedded sound files: Under some
conditions, the frame windows remain white/gray until the embedded audio file
are loaded. There are various ugly scenarios with even uglier workarounds.
Microsoft IE does not perform well in this area, either.
I have tried to work around this, especially when opening new windows,
by using code like the following before loading framesets into the new window:
document.write('<HTML><BODY bgcolor="#330033"></BODY></HTML>');
document.close();
However, these workarounds don't work, they add even more flicker.
You can see attempts to detract the user from the problem on various web sites.
e.g. www.clickon.com uses a background color fading function before frames are
loaded. However, this is only delaying the loading of content pages and not
a solution.
I have been pressured to come up with something like on www.clickon.com but
I can't deliver because our frameset hierarchy has 2 levels and up to 22 frames
per page.
www.clickon.com demonstrates nicely that the background color of a framesetting
document can be manipulated with document.bgColor, but I tried this and it does
not remove the flicker.
|
||
Comment 3•25 years ago
|
||
bht@actrix.gen.nz, have you tried your example with Mozilla M13?
I'd suggest doing so; Navigator 5.0 will be based on the Mozilla codebase.
Unless you state that you have seen this problem with Mozilla, this bug
will be marked INVALID.
If you want to report this bug for 4.x browsers, please see
http://help.netscape.com/forms/bug-client.htm
Mozilla will follow the HTML 4.0 spec, which probably means no added attributes;
it will also support CSS, which *should* let you specify the inheritance you
want here, if it isn't automatic, although I wouldn't know any details.
Please report back how this works with Mozilla.
Assigning all open "nobody@mozilla.org" bugs to "leger@netscape.com" to weed
thru.
Assignee: nobody → leger
No response, marking bug as invalid. reopen if you can confirm this is a
problem with current mozilla build. See:
ftp://ftp.mozilla.org/pub/mozilla/nightly/latest/
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → INVALID
I have tested this with build 2000022308 (different test case) and I am amazed
how well the browser performs now. The flicker problem is gone!
This is fantastic.
The problem is back, Mozilla flickers even more than all other browsers I know of.
Please ignore my positive comments on 2000-02-27 (until fixed of again of course :).
In Mozilla build 2000022308, framesets used to inherit bgcolor from the document
that was loaded prior to the frameset (probably by accident because I can imagine
that nothing was painted over the old content).
This created very smooth page transitions not found in any other browsers.
An anti-flicker measure such as inheriting bgcolor of the previous document would
help immensly to compensate for the slowness of the browser, at tleast give it some
advantage in frames applications.
I really wonder why frames appear to be totally excluded from any quality control
in this area. What would you say if tables would start rendering this way?
Tables do inherit colors.
In summary, users should not be able to see that the browser window is divided
into frames while documents are loading.
Please see http://www.avenue.co.nz for typical example of the consequences.
Severity: normal → major
Status: VERIFIED → REOPENED
Resolution: INVALID → ---
|
Reporter | |
Comment 10•25 years ago
|
||
Previous document -> frameset -> frame bgcolor inheritance:
Even without any additional attributes and corresponding syntax,
simple inheritance of the bgcolor attribute from the pre-loaded
document would solve 100% of all problems.
If this sounds like an exaggerated statement to you please consider
the fact that a frame cannot be used by JavaScript before at least
a blank document (of any background color) has been loaded into it.
Consequently there is not one single case where a frameset cannot
inherit a background color from a previously loaded document.
Even at browser startup with a blank page, when loading a frameset
into the top window, about:blank can be inherited from, resulting
in completely flicker free frameset display.
The window.open() case where the background color would have to be
passed as a parameter is in principle not different from the first
window because again, about:blank it the page to inherit from.
If this is not desired then a window.open() parameter would be the
first and possibly the only thing to ask for.
How does this compare with Microsoft's colored scrollbars?
Please give it a go.
|
|
||
Comment 11•25 years ago
|
||
Fixing QA contact. Doron, I'm setting this to you since this is currently in
Browser-General. If your the wrong person please move to correct component.
QA Contact: nobody → doronr
|
||
Comment 12•25 years ago
|
||
Well, shoot. This bug won't get anywhere assigned to leger@netscape.com, who
doesn't exist any more ... -->HTML Frames.
Assignee: leger → pollmann
Status: REOPENED → NEW
Component: Browser-General → HTMLFrames
QA Contact: doronr → petersen
|
|
Reporter | |
Comment 13•24 years ago
|
||
|
|
||
Comment 14•24 years ago
|
||
pollmann, I'm nominating for mozilla1.0. Should you own this bug, or is there
someone likelier to fix it soon that you know of?
/be
Keywords: mozilla1.0
|
|
||
Comment 16•24 years ago
|
||
pollmann: Is this on the radar for 1.0, or has it been pushed out beyond that?
Gerv
|
|
||
Comment 18•24 years ago
|
||
I'll try, but... there are lots of other bugs on my plate between now and then.
This might be solvable by the view system? CC'ing Kevin to see what he thinks...
Status: NEW → ASSIGNED
OS: Windows 95 → All
Hardware: PC → All
Target Milestone: Future → mozilla1.0
|
|
Reporter | |
Comment 19•24 years ago
|
||
Good, interesting, exciting. - I hope something will happen soon. Mozilla needs
a few COMPELLING features like this. I mean features that everyone will notice.
One doesn't need to be a propellerhead to see what a difference this makes.
Please consider that improvements will become obvious even without changes in
existing web site designs.
Apart from the fact that the current state of affairs could easily be described
as a design flaw which has been stupidly cloned in other browsers. Who is
leading edge this time? I hope Mozilla is.
|
||
Comment 20•24 years ago
|
||
I think it's fixed now, reporter please verify.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → WORKSFORME
|
|
Reporter | |
Comment 21•24 years ago
|
||
I have just installed build 2001092103. For me, the reporter, the problem is
still there. It is not as bad as it was initially because overall performance
of Mozilla has improved.
I am using Win95 on a 300MHz PC and a Matrox PCI graphics card. On this
platform, the flicker still exists with the latest testcase.
I can clearly see the annoying effect of white about:blank pages being "loaded"
intermediately into the sub-frames, which causes the flicker that is the subject
of this bug.
Maybe someone knows of a clever way to temporarily change the color of
about:blank or to eliminate it completely.
Real world multi-frame sites sometimes look like fireworks to me because of this.
I am really stunned by the awsome rendering power of Mozilla.
IMHO, getting _this_ right would lift frames performance up to the same level.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
|
|
||
Comment 22•24 years ago
|
||
Bulk reassignin HTML FRAME/IFRAME bugs to Eric.
Assignee: pollmann → evaughan
Status: REOPENED → NEW
|
|
Reporter | |
Comment 23•23 years ago
|
||
Possibly of interest: Meanwhile Java Applets are catching up. The previously
grey transient background can now be customised, very much like suggested here
for frames.
Please refer to
http://java.sun.com/j2se/1.4/docs/guide/plugin/developer_guide/special_tags.html
'By default the applet window background color is gray. BOXCOLOR can be used to
specify a different background color. The format is as follows:
BOXCOLOR="<value>"'
|
|
||
Comment 24•23 years ago
|
||
Bulk re-assigning all of Eric's HTMLFrame bugs to John.
Assignee: eric → jkeiser
|
|
||
Comment 25•23 years ago
|
||
Moving to mozilla1.1. Engineers are overloaded!
Target Milestone: mozilla1.0 → mozilla1.1
|
|
||
Comment 27•21 years ago
|
||
roc, is this still a problem now that frames defaul to transparent?
|
|
Reporter | |
Comment 28•21 years ago
|
||
The transparent background color has improved things dramatically in those cases
where transparency has an effect.
However, the problem still remains in other cases where there is nothing for
transparency to be based on e.g. when you load a frameset into a new window.
In such cases, there would be two options:
a) Support a bgcolor attribute in the frame tag
b) Support a bgcolor attribute in the window.open() function and have the
frameset inherit from that new window color.
The thing to do is to make <FRAME>s transparent and then set a background color
on the main document. Actually, I think that works already... I'll attach a
testcase.
Given that this works, I think we should close this bug.
|
|
Reporter | |
Comment 31•21 years ago
|
||
Interesting code. It certainly covers this bug entirely and I agree that it
should be closed.
However, on the practical side it cannot eliminate any flicker that is caused by
the network delay between opening a window and loading the document.
How should a new browser window know what the color of a document is that has
not yet been loaded? That is why window.open() should support a bgcolor parameter.
Please refer to bug 45363 for this.
Status: NEW → RESOLVED
Closed: 24 years ago → 21 years ago
Resolution: --- → WORKSFORME
|
||
Updated•7 years ago
|
Product: Core → Core Graveyard
|
||
Updated•7 years ago
|
Component: Layout: HTML Frames → Layout: Images
Product: Core Graveyard → Core
You need to log in
before you can comment on or make changes to this bug.
Description
•