Bug 48462 - SVG content gets opaque white background
Summary: SVG content gets opaque white background
Status: RESOLVED DUPLICATE of bug 10687
Alias: None
Product: WebKit
Classification: Unclassified
Component: SVG (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Windows 7
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on: 10687
Blocks:
  Show dependency treegraph
 
Reported: 2010-10-27 13:44 PDT by Michael O'Rourke
Modified: 2011-01-27 11:31 PST (History)
5 users (show)

See Also:


Attachments
Content referenced by example HTML files (591 bytes, image/svg+xml)
2010-10-27 13:44 PDT, Michael O'Rourke
no flags Details
HTML which brings in SVG content via <embed> (322 bytes, application/xhtml+xml)
2010-10-27 13:44 PDT, Michael O'Rourke
no flags Details
HTML which brings in SVG content via <img> (324 bytes, application/xhtml+xml)
2010-10-27 13:45 PDT, Michael O'Rourke
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael O'Rourke 2010-10-27 13:44:01 PDT
Created attachment 72079 [details]
Content referenced by example HTML files

When SVG content is brought into HTML via the <object> or <embed> tags the unpainted background of the SVG content is rendered as opaque white.

When SVG content in brought into HTML via the <img> tag the unpainted background of the SVG content is rendered as transparent.

It seems that the <img> tag behaviour is far more useful for compositing content and the correct model for SVG content.

Using the <img> tag is undesirable as it seems to treat the SVG content as an image and then text selection and links in text do not work. These do work when the content is brought in with <object> or <embed> but then the opaque white background limits the usefulness of SVG content.
Comment 1 Michael O'Rourke 2010-10-27 13:44:42 PDT
Created attachment 72080 [details]
HTML which brings in SVG content via <embed>
Comment 2 Michael O'Rourke 2010-10-27 13:45:00 PDT
Created attachment 72081 [details]
HTML which brings in SVG content via <img>
Comment 3 Dirk Schulze 2010-10-27 22:47:26 PDT
The reason seems to be http://trac.webkit.org/browser/trunk/WebCore/rendering/RenderBoxModelObject.cpp#L646
Not sure what the SVG spec is saying.
Comment 4 Jeff Schiller 2010-10-27 23:25:59 PDT
WORKSFORME

Please check with a nightly webkit.  This was fixed for Bug 10687 and the embed displays with a transparent background on my nightly build.
Comment 5 Dirk Schulze 2010-10-28 01:12:46 PDT
(In reply to comment #4)
> WORKSFORME
> 
> Please check with a nightly webkit.  This was fixed for Bug 10687 and the embed displays with a transparent background on my nightly build.

I couldn't check the examples of above, since the circle.svg is not included, nor accessible. But I guess he's not talking about the transparence level, but the color. Can it be that the background of the embedded SVG's are transparent white and on image transparent black? If so, we should make it consistent. This can make a difference on some compositing modes.
Comment 6 Dirk Schulze 2010-10-28 01:13:37 PDT
Hm, maybe I misinterpreted the original comment, sorry.
Comment 7 Michael O'Rourke 2010-10-28 12:05:07 PDT
Bug 10687 does sound like it is the same issue and should resolve my problem.

Sorry about that. I'll try out the nightly build.

Is there a way to tell what version of webkit is in Chrome? So that I can see when the fixed webkit build gets into my Chrome?
Comment 8 Helder Magalhães 2011-01-27 01:59:08 PST
(In reply to comment #4)
> WORKSFORME
> 
> Please check with a nightly webkit.  This was fixed for Bug 10687 and the embed displays with a transparent background on my nightly build.

I confirm this fixed as well (on Windows Vista SP2 with Chrome 10.0.648.6 dev) - I'd vote this closed as well: WFM (as Jeff suggested) or even as a dup. of bug 10687, as that underlying issue is more generic and also older than this one (although a dependency was already set). :-)

BTW: Great work in #10687, Jeff! ;-)
Comment 9 Alexey Proskuryakov 2011-01-27 11:31:04 PST
Please feel free to re-open if this is still an issue.

*** This bug has been marked as a duplicate of bug 10687 ***