Bug 18308

Summary: REGRESSION: SVG Encoding error with fill attribute
Product: WebKit Reporter: Dmitriy Dzema <dmitriy>
Component: Page LoadingAssignee: Alexey Proskuryakov <ap>
Status: RESOLVED FIXED    
Severity: Normal CC: ap
Priority: P1 Keywords: Regression
Version: 525.x (Safari 3.1)   
Hardware: Mac   
OS: OS X 10.4   
URL: http://monopoly.dzema.name/webkit_bug/
Attachments:
Description Flags
How it looks
none
Test page
none
Fix a WebKit part of the problem darin: review+

Dmitriy Dzema
Reported 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.
Attachments
How it looks (14.36 KB, image/png)
2008-04-03 23:50 PDT, Dmitriy Dzema
no flags
Test page (1.27 KB, text/html)
2008-04-03 23:51 PDT, Dmitriy Dzema
no flags
Fix a WebKit part of the problem (11.29 KB, patch)
2008-04-07 04:11 PDT, Alexey Proskuryakov
darin: review+
Dmitriy Dzema
Comment 1 2008-04-03 23:50:18 PDT
Created attachment 20327 [details] How it looks
Dmitriy Dzema
Comment 2 2008-04-03 23:51:35 PDT
Created attachment 20328 [details] Test page
Alexey Proskuryakov
Comment 3 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!
Alexey Proskuryakov
Comment 4 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.
Alexey Proskuryakov
Comment 5 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>">
Alexey Proskuryakov
Comment 6 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.
Darin Adler
Comment 7 2008-04-27 23:45:48 PDT
Comment on attachment 20378 [details] Fix a WebKit part of the problem r=me
Alexey Proskuryakov
Comment 8 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.
Note You need to log in before you can comment on or make changes to this bug.