Bug 17744

Summary: SVG opened in object does not honor transparent background
Product: WebKit Reporter: Shelley Powers <shelleyp>
Component: SVGAssignee: Nobody <webkit-unassigned>
Status: RESOLVED DUPLICATE    
Severity: Normal CC: c.1, heycam, jeffschiller
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Mac   
OS: OS X 10.4   
URL: http://burningbird.net
Attachments:
Description Flags
Small test case none

Shelley Powers
Reported 2008-03-10 07:11:31 PDT
If you open an SVG file using the object element, and the element has a transparent background (no background color is specified for the SVG), WebKit/Safari paints the background white. I've tried to set the background to transparent in the SVG, in the object, nothing works.
Attachments
Small test case (37 bytes, text/plain)
2009-07-15 04:15 PDT, Cameron McCormack (:heycam)
no flags
Eric Seidel (no email)
Comment 1 2008-04-13 22:56:57 PDT
I just saw another bug like this tonight, but they were using wmode="transparent" to get this behavior. I wonder if the same would work for you. (the wmode bug did not reproduce for me, I think they were using an SVG plugin, instead of WebKit's built-in SVG support).
Shelley Powers
Comment 2 2008-04-14 07:15:08 PDT
The page has a background color, which was hidden with both Safari (including Webkit) and Opera, but not with Firefox 3. I put a background on the object itself to fix. To demonstrate, I added the two SVG elements as objects, removed any background color and the following snapshot shows what the page looks like in Webkit: <a href="http://skitch.com/shelleyp/jxta/burningbird"><img src="http://img.skitch.com/20080414-t1u3fmn1kspnhr6befpanwppw3.preview.jpg" alt="Burningbird" /></a> However, same page with Firefox: <a href="http://skitch.com/shelleyp/jx1d/burningbird"><img src="http://img.skitch.com/20080414-c7792ac8j22nkxniajgkab5ey8.preview.jpg" alt="Burningbird" /></a> What's interesting, though, is that I used wget to create a <a href="http://burningbird.net/svgerror/burningbird.net">snapshot of the page</a> to preserve the bug, but Safari/Webkit now picks up the background color. The only difference? One site is dynamic, the other is a static web page. I'll leave the front page up for a time so you can see the bug, but I can't preserve the web page indefinitely. Hopefully the images will be enough to show how to recreate the bug.
Shelley Powers
Comment 3 2008-04-14 07:20:08 PDT
Correction, it works when the page is served up as HTML, not when the page is served up as XHTML. That's the difference.
Shelley Powers
Comment 4 2008-04-14 07:29:04 PDT
(In reply to comment #3) > Correction, it works when the page is served up as HTML, not when the page is > served up as XHTML. That's the difference. > Now that I know the exact problem, I've created static sites to serve for confirmation of this bug. The first site, http://burningbird.net/svgerror/burningbird.net/, serves the page up as HTML and Safari/Webkit processes the background color properly. The second site, at http://burningbird.net/svgerror/xburningbird.net/, serves the page up as XHTML, and the background color is not coming through. That's the only difference between the two pages.
CPK Smithies
Comment 5 2009-06-25 09:39:42 PDT
Confirm this problem exists under MacOS only, glaringly inconsistent with all other browsers including webkit under Windows, tested unaffected by mime type with which the page is served, problem exhibited by http://grainger-quartet.co.uk/
CPK Smithies
Comment 6 2009-06-25 20:28:31 PDT
This bug also occurs in the Linux 32-bit Ubuntu build of the chromium-browser, webkit build 531.
Cameron McCormack (:heycam)
Comment 7 2009-07-15 04:15:16 PDT
Created attachment 32775 [details] Small test case Attachment has a smaller test case. Shows a 100x100 green rectangle in Firefox 3.5 and Opera 10a, shows plain white in WebKit.
Cameron McCormack (:heycam)
Comment 8 2009-07-15 17:42:02 PDT
*** This bug has been marked as a duplicate of bug 10687 ***
Note You need to log in before you can comment on or make changes to this bug.