Bug 18308 - REGRESSION: SVG Encoding error with fill attribute
Summary: REGRESSION: SVG Encoding error with fill attribute
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Page Loading (show other bugs)
Version: 525.x (Safari 3.1)
Hardware: Macintosh OS X 10.4
: P1 Normal
Assignee: Alexey Proskuryakov
URL: http://monopoly.dzema.name/webkit_bug/
Keywords: Regression
Depends on:
Blocks:
 
Reported: 2008-04-03 23:48 PDT by Dmitriy Dzema
Modified: 2008-05-19 12:23 PDT (History)
1 user (show)

See Also:


Attachments
How it looks (14.36 KB, image/png)
2008-04-03 23:50 PDT, Dmitriy Dzema
no flags Details
Test page (1.27 KB, text/html)
2008-04-03 23:51 PDT, Dmitriy Dzema
no flags Details
Fix a WebKit part of the problem (11.29 KB, patch)
2008-04-07 04:11 PDT, Alexey Proskuryakov
darin: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dmitriy Dzema 2008-04-03 23:48:15 PDT
Page is in the windows-1251 encoding, SVG embeded as objects. Then there is an attribute fill on tspan tag, the text is corrupted and Safari shows encoding error. The same svg code without fill attribute works perfectly. If page is in utf-8 both svg's works.
Comment 1 Dmitriy Dzema 2008-04-03 23:50:18 PDT
Created attachment 20327 [details]
How it looks
Comment 2 Dmitriy Dzema 2008-04-03 23:51:35 PDT
Created attachment 20328 [details]
Test page
Comment 3 Alexey Proskuryakov 2008-04-07 01:19:09 PDT
On 10.5 with Safari 3.1, both variants are displayed incorrectly. Also, having the main page in UTF-8 doesn't help. Marking as regression.

I think that this is a data: URL issue, not something related to SVG. For whatever reason, the two subresources are encoded differently when loaded. One is encoded as windows-1251, and another as UTF-8 - but both are decoded as US-ASCII!
Comment 4 Alexey Proskuryakov 2008-04-07 01:39:11 PDT
We've got at least two bugs here. One is in WebKit, and is responsible for the two variants being displayed differently - the presence of a "#" character in the URL makes encodeRelativeString() assume that we have a fragment, and encode it differently, which is incorrect for data: URLs. Another bug is that we use an US-ASCII codec for decoding a response - it may be seen as a CFNetwork bug that it gives us wrong information about response encoding.
Comment 5 Alexey Proskuryakov 2008-04-07 02:19:59 PDT
Workaround: add an explicit charset to the MIME type, AND percent-escape the hash symbol:

<object class="obj" type="image/svg+xml"  height="600px"
 data="data:image/svg+xml;charset=utf-8,
 <svg xmlns='http://www.w3.org/2000/svg'>
  <text font-weight='bold' x='-500' y='145' font-size='35px' transform='rotate(-90)'>
   <tspan x='-500' dy='-40' fill='%23FED062'>foo</tspan>
  </text>
 </svg>">

Comment 6 Alexey Proskuryakov 2008-04-07 04:11:47 PDT
Created attachment 20378 [details]
Fix a WebKit part of the problem

This fixes the treatment of "#" character, but one will still need to explicitly declare the charset. Filed <rdar://problem/5845875> for that.
Comment 7 Darin Adler 2008-04-27 23:45:48 PDT
Comment on attachment 20378 [details]
Fix a WebKit part of the problem

r=me
Comment 8 Alexey Proskuryakov 2008-05-19 12:23:36 PDT
Committed revision 33578. As mentioned above, part of the bug is not in WebKit, and will be tracked by Apple internally.