Closed
Bug 50623
Opened 24 years ago
Closed 22 years ago
Background transparency isn't honored inside OBJECT's and IFRAME's
Categories
(Core :: Web Painting, defect)
Core
Web Painting
Tracking
()
VERIFIED
FIXED
mozilla1.1alpha
People
(Reporter: bugmail, Assigned: roc)
References
()
Details
(Keywords: css1, testcase)
Attachments
(3 files, 2 obsolete files)
(deleted),
image/png
|
Details | |
(deleted),
patch
|
dbaron
:
review+
waterson
:
superreview+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
Details | Diff | Splinter Review |
An IFRAME that specifies no background style, embedded in a document with a
specified background style, is rendered with the background of the default
viewport or canvas, when it should probably display with no background, or a
theoretical "transparent" background.
Reproducibility: every time.
Steps to reproduce: Load the specified example case URL
Actual results: Observe that the page renders with an overall blue background,
but the IFRAME displays with whatever color is specified as the default
background color in the browser preferences.
Expected results: The IFRAME should display with no background; that is, a
theoretically "transparent" background, resulting in the text "This is bar."
being rendered on a blue background.
Additional information: I verified the behavior with the 8/28 M18 daily build as
well.
This "bug" may simply be a misinterpretation of the intended background of an
IFRAME element or how background colors and images are inherited from the
embedding document and the viewport or canvas.
It's important to consider what would happen if instead of a solid blue
background, a more complex image were used as a background instead. In such a
case, the background image shouldn't be retiled again at the top-left corner of
the IFRAME; the IFRAME should, I believe simply be "transparent", as specified
above.
This also conjurs up notions of fully "transparent" (or, god forbid,
translucent) pages, but I don't believe that issue needs to be addressed to fix
this bug, which is only intended to address the backgrounds of IFRAMEs embedded
in HTML or XML documents. (Note also that OBJECT functionality is tested in the
example, but as text/html OBJECT embedding is presently nonfunctional it cannot
be tested.)
Comment 1•24 years ago
|
||
It would be nice, but it is not critical, so we'll get to it during a future
feature train (we are currently concentrating on stability fixes).
Moving to Views, which I believe is the right component...
Assignee: pierre → kmcclusk
Status: UNCONFIRMED → NEW
Component: Style System → Views
Ever confirmed: true
Keywords: css1
OS: Mac System 9.0 → All
Hardware: Macintosh → All
Target Milestone: --- → Future
Assignee | ||
Comment 2•24 years ago
|
||
This can and should be fixed, but after NS6 ships, and probably even post
Mozilla 1.0.
I think the best way is to just have just one nsViewManager for an entire
document and all its subdocuments. In other words, the root view of an IFRAME
document is not the root of the view tree. Such a view would have to be
specially marked as a document root view to make fixed-position elements attach
to the right parent, but there's nothing on the view manager side to make any of
this difficult. The difficulties are probably in places like the docshell where
it assumes it controls its own view manager.
Once there's just one view manager for the entire document set, transparency,
translucency and other tricks are easily taken care of.
Updated•24 years ago
|
Summary: IFRAME element that specifies no background itself doesn't interact properly with background of embedding document → IFRAME element that specifies no background itself doesn't interact properly with background of embedding document [BG]
Updated•24 years ago
|
QA Contact: chrisd → petersen
Updated•24 years ago
|
Status: NEW → ASSIGNED
*** Bug 75718 has been marked as a duplicate of this bug. ***
Since bug 678 has been fixed, this now applies to OBJECT elements as well as
IFRAME elements.
Summary: IFRAME element that specifies no background itself doesn't interact properly with background of embedding document [BG] → Transparent documents in OBJECT's and IFRAME's aren't displayed transparently.
fyi
Ive filed a request for a possible work around (for background color) if the
iframe transparency fix is post 1.0 (see 105821) ....
.... but I too would love to see iframe transparency fixed for 1.0 to eliminate
the default white background
Summary: Transparent documents in OBJECT's and IFRAME's aren't displayed transparently. → Background transparency isn't honored inside OBJECT's and IFRAME's
Assignee | ||
Comment 7•23 years ago
|
||
I am planning to (very soon) add support in the view system for transparent IFRAMEs.
However, with our current style rules an IFRAME will not be transparent by
default. We treat it just like a top-level document; it has a canvas whose
background is always set according to user prefs or system colours, if not by
the document itself. However, you will probably be able to force it to be
transparent by putting this rule in a style sheet:
:canvas { background: transparent; }
Giving IFRAMEs a transparent background by default would require a little more
work and be a significant policy decision, so ccing W3C standards gurus.
Assignee | ||
Comment 8•23 years ago
|
||
OK, I now have support for this in my tree. However, you won't be getting
transparent backgrounds by default. You'll have to use funky style rules to set
them.
Assignee: kmcclusk → roc+moz
Status: ASSIGNED → NEW
Assignee | ||
Comment 9•23 years ago
|
||
To get this to work I added the following to my userContent.css:
html, body, *|*:viewport, *|*:viewport-scroll, *|*:canvas, *|*:root {
background: transparent; }
Assignee | ||
Comment 10•23 years ago
|
||
The mechanism for this landed a while ago. If you add those horrible styles to
your IFRAME document it should be transparent. Now we're just waiting for the
W3C gurus to tell us when exactly an IFRAME should be transparent.
Severity: normal → minor
Priority: P3 → --
Target Milestone: Future → mozilla1.1
Reporter | ||
Comment 11•23 years ago
|
||
Robert, does this work for both IFRAME and OBJECT?
Assignee | ||
Comment 12•23 years ago
|
||
Yes it does.
Reporter | ||
Comment 13•23 years ago
|
||
Incorporating Robert's userContent.css settings, the testcase URL does now
appear to work as expected using Mac/2002022108.
Comment 14•23 years ago
|
||
I guess looks like safe to enable this when pages are specifying
background-color transparent for the body element. Example
<body style="background-color:transparent">. This will really enable a new world
of possibilities. I am thinking.. can I plugin canvas have transparent
background? will flash transparent work?
Comment 15•23 years ago
|
||
Adding few DHTML gurus.
Assignee | ||
Comment 16•23 years ago
|
||
Plugins won't generally work with transparency. They will appear completely
opaque. (There is some support for transparent plugins but I don't think the
plugin vendors use it.)
Comment 17•23 years ago
|
||
About the plugins, bug 99974 is about transparency in Flash movies.
Comment 18•23 years ago
|
||
I believe that IFRAMEs and so forth should not be transparent by default, but
should act as transparent if their background is set to 'transparent'.
Assignee | ||
Comment 19•23 years ago
|
||
I presume you mean that they should be transparent if the background on the BODY
and HTML elements of the contained document is set to "transparent". Right?
Comment 20•23 years ago
|
||
That would work. Note that if the frame is empty it should still be white --
that should not be a problem because about:blank is an HTML document with a BODY
element which should be getting its background from html.css.
Except I don't think we do it that way at the moment -- aren't all body elements
transparent by default?
Comment 21•22 years ago
|
||
Why should an iframe that is empty be white instead of transparent?
why do we even have the
*|*:viewport, *|*:viewport-scroll, *|*:canvas
rules (*|*:root seemsto be gone)? Shouldn't they simply be killed? Is there a
bug tracking that? (or is that bug this bug :) )
Assignee | ||
Comment 23•22 years ago
|
||
I tested this with Ian's background tests, some general surfing, and some
complex IFRAME tests I made up. It has the effect of making IFRAMEs transparent
by default because their documents don't have any background set (of course, if
an IFRAME specifies a background on its HTML or BODY element, it is honoured).
I recommend that this be checked in.
Assignee | ||
Comment 24•22 years ago
|
||
Ian should review this patch.
Note that it makes about:blank frames (and any document without background
explicitly set) transparent. Our mechanism for setting prefererred/system
background colors only applies to the root document (and it still works, I
checked). If we want to apply that mechanism to subdocuments (and I don't
actually see why we should) then file another bug about that but still check in
this patch.
Assignee | ||
Comment 25•22 years ago
|
||
This patch includes the previous patch and adds a fix that makes "background"
styles work on frames. This is very useful now that the document contained in a
frame can be transparent; the background of the frame element in the enclosing
document will be visible.
The background style fix undoes a hack that I did in patch 49779. Since that
bug we've added the new CanPaintBackground method which is a cleaner way to
handle frames that don't paint backgrounds.
Attachment #85000 -
Attachment is obsolete: true
Comment 26•22 years ago
|
||
I don't understand really the patch itself. Let me see if I can understand what
it does, though.
First, what are the defaults. An unspecified background color for the root
element of a document results in a computed background of 'transparent'? Does
the ::canvas then have a default background that matches the user's colours?
Do <frame>s default (due to CSS initial values) to a 'transparent' background?
If so, would the following describe the effect of the patch?:
Document | <frame> | Subdocument | Result
Background | Background | Background |
--------------+--------------+---------------+---------------------------------
unspecified | unspecified | unspecified | Document shines through to be
| | | the subdocument's background, so
| | | typically the user's preferred
| | | colours are used.
| | |
red | green | transparent | Subdocument background is green.
| | |
red | maroon | green | Subdocument background is green.
| | |
green | rgba(1,1,1,1)| rgba(2,2,2,2) | rgba(2,2,2,2) composited on top
| | | of rgb(1,1,1,1) composited on top
| | | of green.
| | |
Assignee | ||
Comment 27•22 years ago
|
||
> An unspecified background color for the root
> element of a document results in a computed background of 'transparent'?
Yes.
> Does the ::canvas then have a default background that matches the user's
> colours?
The CSS background for all ::canvases is transparent, but dbaron's painting code
ensures that when we paint the background for the ::canvas of a document at the
root of a document tree, we use the user's colours.
> Do <frame>s default (due to CSS initial values) to a 'transparent'
> background?
Yes.
> If so, would the following describe the effect of the patch?
Yes.
Status: NEW → ASSIGNED
Comment 28•22 years ago
|
||
Cool. Technically at least, that sounds good to me.
We may need to make <iframe>s have non-transparent backgrounds in quirks mode,
though, if there are sites that are affected by this in odd ways.
Reporter | ||
Comment 29•22 years ago
|
||
So, does this need the "review" keyword now?
Assignee | ||
Comment 30•22 years ago
|
||
There's just one thing I'm a little worried about. I don't know why frames
aren't transparent today! The initial value for "background-color" is
"transparent" in CSS2, and that's what we seem to implement. "-moz-viewport",
"-moz-viewport-scroll" and "-moz-canvas" should all be inheriting that, so the
guts of this patch (removing the "inherit", giving them the initial value of
"transparent") should have no effect! Yet it does. I've stared at the code but I
can't figure out how -moz-viewport is inheriting anything other than
"transparent". Maybe dbaron can help me out...
Comment 31•22 years ago
|
||
The nsStyleBackground constructor for the root style context (taking an
nsIPresContext) initializes background differently. Also see
nsCSSRendering::FindBackground.
Comment 32•22 years ago
|
||
Comment on attachment 85004 [details] [diff] [review]
Better patch
sr=waterson
Attachment #85004 -
Flags: superreview+
Assignee | ||
Comment 33•22 years ago
|
||
dbaron, you're talking about
http://lxr.mozilla.org/seamonkey/source/content/shared/src/nsStyleStruct.cpp#979
right? That seems to make the root style context transparent. Maybe the
BG_IS_TRANSPARENT flag is somehow being ignored so the prescontext colour is
used, but I don't see how.
I know about FindBackground but that doesn't affect the styles inherited into
the viewport.
Comment 34•22 years ago
|
||
Oh, you're right about the nsStyleBackground constructor. How about the code in
nsCSSRendering::PaintBackground (not FindBackground)?
Comment 35•22 years ago
|
||
Heh. Are we still trying to work out how the canvas background ends up being
painted? IIRC Pierre couldn't work that out either, about 2 years ago...
Assignee | ||
Comment 36•22 years ago
|
||
PaintBackground ignores a transparent canvas and paints it with the default
colour BUT ONLY for root documents, not (since my changes in the 0.9.9
timeframe) for framed documents. So that doesn't explain why the current code
paints the canvases of framed documents.
Anyway (unless I'm on crack) the current code behaves differently with when I
change ":-moz-viewport { background-color: inherit; }" to ":-moz-viewport {
background-color: transparent; }", which makes no sense since it should be
inheriting transparent and so no difference should be visible outside the style
system.
OK, so no-one knows what's going on. I'll try some more invasive analysis.
Assignee | ||
Comment 37•22 years ago
|
||
HA. So I just uncovered a subtle but potentially serious style system bug.
nsRuleNode.cpp has lots of constructs like this:
> bg->mBackgroundFlags &= ~NS_STYLE_BG_COLOR_TRANSPARENT;
> bg->mBackgroundFlags |= (parentBG->mBackgroundFlags &
NS_STYLE_BG_COLOR_TRANSPARENT);
Looks fine, doesn't it? But think about the case when bg == parentBG. This
happens whenever parentContext is null but it can happen for various settings of
ruleDetail. The only reason we don't get burned much is because the default
style context doesn't have many flags set so not much gets accidentally dropped.
Assignee | ||
Comment 38•22 years ago
|
||
Here's the real fix: stop the style system from forgetting about transparency
when bg == parentBG. Also fixes <frame>/<iframe> frames to draw backgrounds, as
noted above.
Attachment #85004 -
Attachment is obsolete: true
Comment 39•22 years ago
|
||
Comment on attachment 85585 [details] [diff] [review]
The REAL fix
r=dbaron, except:
Why doesn't the FRAME/IFRAME paint its background when it has a nontransparent
one? (In other words, why do you need to add the |CanPaintBackground|
override?) It looks like you're changing it so that's not necessary.
Also, the comment in the nsRuleNode.cpp change should either say "save
parentFlags" or "save parent flags" rather than "save parentFlag".
Attachment #85585 -
Flags: review+
Assignee | ||
Comment 40•22 years ago
|
||
> Why doesn't the FRAME/IFRAME paint its background when it has a
> nontransparent one? (In other words, why do you need to add the
> |CanPaintBackground| override?) It looks like you're changing it so that's
> not necessary.
FRAME/IFRAME elements generate two frames. nsFrameOuterFrame paints the
background, but nsFrameInnerFrame does not (and that's where the
CanPaintBackground() -> PR_FALSE is).
> Also, the comment in the nsRuleNode.cpp change should either say "save
> parentFlags" or "save parent flags" rather than "save parentFlag".
I'll fix that.
Comment 41•22 years ago
|
||
OK, makes sense to me.
Assignee | ||
Comment 42•22 years ago
|
||
I just want to clarify something for posterity:
As it stands this patch is just bugfix and cleanup. It turns out our policy as
expressed in CSS rules was already to make FRAME/IFRAME transparent by default,
it just wasn't implemented correctly :-). If we get feedback that FRAME/IFRAME
should not be transparent by default then the solution is NOT to rollback this
patch, but to modify the style system so that every ::viewport has its
background colour set in CSS to the user's preferred colour.
Comment 43•22 years ago
|
||
Comment on attachment 85585 [details] [diff] [review]
The REAL fix
sr=waterson
Attachment #85585 -
Flags: superreview+
Assignee | ||
Comment 44•22 years ago
|
||
Checked into trunk.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Comment 45•22 years ago
|
||
This broke Tinderbox.
Specifically, it made the <iframe>s that appear when you click someone's name
appear transparent, which looks really ugly. This is what I thought might happen
(see comment 28). What do we want to do about this? I think per the spec, we are
justified in our behaviour (the <iframe>'s infinite canvas is merely
transparent) but do we really want to evangelise any sites that this breaks? Is
this a quirks/standards thing?
VERIFIED FIXED.
Status: RESOLVED → VERIFIED
Assignee | ||
Comment 46•22 years ago
|
||
It's not THAT bad, I wouldn't say it "broke" Tinderbox. Actually it shows how
useful transparent IFRAMEs will be: the Tinderbox people should set the popup
IFRAMEs to have no border, then you get the effect of IFRAMEed content that
sizes to fit the contents, which you can't get otherwise.
I'll try to prepare a patch that restores the old behavior by setting the
initial background for the viewport. Once we collect more feedback we can decide
whether or not to apply the patch.
Comment 47•22 years ago
|
||
If we did that, what would be the standards-compliant CSS that would make the
iframe transparent again?
Assignee | ||
Comment 48•22 years ago
|
||
I guess we should set the initial background for the root element, so that <html
style="background: transparent"> would suffice.
Assignee | ||
Comment 49•22 years ago
|
||
Setting the <html> background doesn't work because that screws up the
body->canvas inheritance path. I guess this can't be done with style rules. I'll
hack FindBackground/PaintBackground instead.
Assignee | ||
Comment 50•22 years ago
|
||
OK, I'm stumped.
If we use CSS rules to set the style on <HTML> to anything non-transparent, then
we break the propagation of non-transparent <BODY> to the canvas. But if we
don't use CSS rules to set the style on <HTML>, then how can authors get a
transparent background in a standards-compliant way?
Comment 51•22 years ago
|
||
How about putting the background on the <iframe> itself, so that authors wanting
transparent iframes just have to say:
iframe { background: transparent; }
...? Would that work?
Assignee | ||
Comment 52•22 years ago
|
||
Yes! That's a brilliant idea and it does work. Patch coming up.
Assignee | ||
Comment 53•22 years ago
|
||
Comment 54•22 years ago
|
||
Comment on attachment 85926 [details] [diff] [review]
Give IFRAMEs the user's preferred background
You're going to want to put those selectors in the HTML namespace somehow.
(This stylesheet should probably be rewritten as a separate C++ implementation
of nsIStyleSheet at some point. Perhaps this is the time.)
Assignee | ||
Comment 55•22 years ago
|
||
nsPresShell sets XHTML as the default namespace for the style sheet:
> mPrefStyleSheet->SetDefaultNameSpaceID(kNameSpaceID_XHTML);
Isn't that good enough?
Comment 56•22 years ago
|
||
OK. Never mind...
Comment 57•22 years ago
|
||
Well, do mind. The ":root" and "*" selectors should be in all namespaces,
otherwise this will only work for (X)HTML documents. Also, we should add
pseudo-elements, otherwise authors can override this.
So the rules in the second part should be:
*|*:root {
color: bla ! important; background: bla ! important;
}
*|*, *|*:before, *|*:after, *|*:first-line, *|*:first-letter {
color: inherit ! important; background: transparent ! important;
}
And of course that's ignoring the mirad :-moz-* pseudo-elements that we're
leaving open to abuse...
Comment 58•22 years ago
|
||
That will cause the creation of lots of pseudo-element frames that we don't need
in the case where the override pref is checked.
We really need to redo the way these prefs work (the override ones should be
handled in nsRuleNode.cpp).
Assignee | ||
Comment 59•22 years ago
|
||
In nsRuleNode.cpp can we determine whether the styled element(s) belong to
content to which prefs should be applied?
If we had some internal rule selector that applied to absolutely everything, we
could use that.
Comment 60•22 years ago
|
||
Um.
It really shouldn't create new pseudo-element nodes unless our code is on crack,
since those rules specifically put those pseudo-elements back to their initial
values, in the case of :first-line and :first-letter, and don't affect the
'content' property, in the case of :before and :after.
A magic pseudo-element that applies to all elements, real and fake, might be
best though, I guess. Hey, you guys are the experts. :-)
Assignee | ||
Comment 61•22 years ago
|
||
I'm curious --- why doesn't * apply to pseudoelements? It seems a bit strange to
have a selector that selects everything except pseudoelements.
Comment 62•22 years ago
|
||
It's a theoretical thing. It basically doesn't fit into the CSS conceptual model.
The * is the type selector which is implied in ".class". Having that also mean
".class::before" would be bad. And so on.
Comment 63•22 years ago
|
||
Adding mkaply
Tis is the bug that caused iframes to have transparent backgrounds; there's a
patch here that changes that.
Updated•6 years ago
|
Component: Layout: View Rendering → Layout: Web Painting
You need to log in
before you can comment on or make changes to this bug.
Description
•