[Webkit-unassigned] [Bug 35349] New: IFrame background rendered white until loading of src url

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Feb 24 10:23:55 PST 2010


https://bugs.webkit.org/show_bug.cgi?id=35349

           Summary: IFrame background rendered white until loading of src
                    url
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: PC
        OS/Version: Mac OS X 10.5
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: Layout and Rendering
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: mihnea at adobe.com


Hi,

I use the following HTML:

<div style="float: left; background-color: rgb(0, 255, 0); width: 320px;
height: 240px;">
    <iframe id="frame1" style="width:200px; height: 200px;"
src="http://www.adobe.com/devnet">
    </iframe>
</div>

After Safari 4 beta, more exactly after changes from:
http://trac.webkit.org/changeset/43646, the background of the frame is rendered
as white until the site is loaded.
The problem appears from the following line from RenderBoxModelObject.cpp
function paintFillLayerExtended:
...
HTMLElement* body = document()->body();
if (body) {
    // Can't scroll a frameset document anyway.
    isOpaqueRoot = body->hasLocalName(framesetTag);
}
... 

Before loading the document in the iframe, the body of the document is null and
therefore the frame is considered opaque. Before this change, in changeset
42348, there was a check for transparency in the same function:
isTransparent = !body || !body->hasLocalName(framesetTag);

If the current code is changed to take into account that the body can be null:
HTMLElement* body = document()->body();
if (body) {
    // Can't scroll a frameset document anyway.
    isOpaqueRoot = body && body->hasLocalName(framesetTag);
}
then the iframe is considered to be transparent and the white background is
gone.

The problem can be seen on latest WebKit, Safari 4.0.4, Chrome on both Win/Mac.
FF3.5.7 does not have the problem.

I tend to say this is a bug but please feel free to correct me if i am wrong
and the normal behavior should be like it is now.

Regards,
Mihnea Ovidenie

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list